Guadagnare con le APP$ (Internet e Web Design) (Italian Edition)
Author: Zanzottera, Paolo
Date: 2014-04-28
Publisher: Hoepli
Rights: Tutti i diritti riservati

GUADAGNARE
CON LE APP$

Paolo Zanzottera

GUADAGNARE
CON LE APP$

Promuovere, vendere e fare business
con le applicazioni

EDITORE ULRICO HOEPLI MILANO

Copyright © Ulrico Hoepli Editore S.p.A. 2014
via Hoepli 5, 20121 Milano (Italy)
tel. +39 02 864871 – fax +39 02 8052886
e-mail hoepli@hoepli.it

Seguici su Twitter: @Hoepli_1870
www.hoepli.it

Tutti i diritti sono riservati a norma di legge
e a norma delle convenzioni internazionali

ISBN 978-88-203-6399-4

Progetto editoriale – Maurizio Vedovati – Servizi editoriali info@iltrio.it
Copertina: Sara Taglialegne

Realizzazione digitale: Promedia, Torino

SOMMARIO

NOTA SULL’AUTORE

INTRODUZIONE

CAPITOLO 1

Il mondo delle applicazioni

L’evoluzione dei dispositivi mobili

Breve storia degli app store

Numeri e mercati attuali

Facciamo un po’ di ordine: differenze tra app e web app/m-site

CAPITOLO 2

Tipologie di applicazioni

Un tentativo di classificazione delle app

Le categorie di utilizzo

I sistemi operativi

Applicazioni per smartphone e per tablet

La scelta tecnologica: app native, web app, widget

CAPITOLO 3

Applicazioni e World Wide web

Differenze e sinergie della comunicazione del web e delle app

Brevi cenni sugli m-site

Trasformare i siti web in m-site o applicazioni

Caso studio Tgcom24

CAPITOLO 4

Progettare un’applicazione: dall’idea al progetto

Idea, obiettivi, modello di business

Caso pratico 1: produttore di sci

Caso pratico 2: produttore di alimenti per neonati e bambini

Analisi del mercato e della concorrenza

ASO e analisi dei risultati degli app store

L’importanza del nome e dell’icona

So.Lo.Mo.

Smartphone non dumbphone: sfruttare la sensoristica di bordo

Caso studio: Condom08

CAPITOLO 5

La creazione della Beta app

Le scelte: team di sviluppo, piattaforme, SO, tecnologia

Cose da sapere… anche se non sei un grafico

Elementi di interfaccia standard

Cose da sapere… anche se non sei un programmatore

Test di usabilità

CAPITOLO 6

Guadagnare con le Applicazioni

Tipologie di remunerazione e numeri del mercato attuale

Applicazioni in vendita (tout court)

Applicazioni gratuite limitate (c.d. app lite), in via di estinzione

Applicazioni gratuite con possibilità di in-app purchase della versione Full/Premium e di feature varie

CAPITOLO 7

App gratuite e modelli di business

Applicazioni gratuite e possibilità di guadagno

Applicazioni gratuite con modello di business “a monte”

Applicazioni aziendali in ambito B2B

Applicazioni gratuite sinergiche per la comunicazione di marchi offline e online

Applicazioni gratuite per la creazione di audience pura: l’importanza della base utenti

Guadagnare con la pubblicità: funzionamento della pubblicità nelle app

Tipologie pubblicitarie lato publisher, metriche e rapporti degli incassi e loro analisi

CAPITOLO 8

Finalmente negli store!

Chi va piano va sano e lontano

Il marketing dell’app comincia da qui: launch checklist

Il processo di sottomissione dell’Apple App Store

Il processo di sottomissione di Google Play

CAPITOLO 9

Marketing delle Applicazioni

Creazione della comunicazione parallela

ASO on-app: la SEO on-page delle app e ottimizzazione della scheda dello store

ASO off-app: la SEO off-page delle app, coinvolgere gli utenti

Pricing delle app e codici di promozione

Gestione di campagne pubblicitarie

Piattaforme per inserzionisti

Campagna su piattaforma iAd

Campagna su piattaforma AdMob

Campagna su piattaforma Facebook

Trucchi e suggerimenti per emergere

CAPITOLO 10

App & Store Analytics

App & Store Analytics: misurare le performance delle Applicazioni

Metriche specifiche dell’App Analytics

Metriche specifiche della Store Analytics

Come e che cosa misurare

Oggetti Multimediali in-app: Video e Audio App Analytics

Dai report all’azione: il processo di miglioramento continuativo

APPENDICE

Futuro

Fare business con i dispositivi mobili e con le app di terze parti

Le app per il tracking delle persone

Le app per Internet delle cose

App e mobile payment

INFORMAZIONI SUL LIBRO

NOTA SULL’AUTORE

PAOLO ZANZOTTERA

Inizia a lavorare come SEO nel 1998 durante i suoi studi universitari e ad analizzare i log file per fare le prime analisi di web analytics.

Nel 2000 si laurea in economia presso l’università Bocconi con una tesi dal titolo “La tutela del consumatore nel mercato digitale”, preparata lavorando attraverso una Internship presso la Commissione Europea a Bruxelles. Alla fine del 2001 torna in Italia e fonda la web agency Bizonweb (www.bizonweb.it) orientata a progetti di e-commerce e marketing digitale. È membro del Board di ShinyStat – piattaforma di digital analytics in tempo reale (www.shinystat.com) – dal 2007. Si è occupato direttamente della creazione della Video Analytics nel 2009 e dell’App Analytics nel 2011.

Dal 2013 è co-fondatore della start-up Appocrate.it (www.appocrate.it): società dedita allo sviluppo di soluzioni digitali in campo medicale, con particolare attenzione ai dispositivi mobili.

Ama moltissimo lo scambio della conoscenza: da anni tiene lezioni e conferenze presso differenti università e organizzazioni pubbliche e private. Padre orgoglioso, adora suo figlio più dello smartphone… E non è poco!

INTRODUZIONE

Questo libro non è un manuale tecnico per creare applicazioni! Ho voluto scrivere un testo alla portata di tutti, cercando di semplificare i concetti più complessi, per renderli comprensibili a chiunque, soprattutto a chi non lavora in ambito digitale. Durante la stesura di queste pagine, mi sono sempre immaginato di spiegare gli argomenti a mia madre e a mio padre, che non sono più molto giovani, ma che hanno scoperto la rete e le applicazioni dopo che ho regalato a mio padre un iPad, per i suoi ottant’anni… e non aveva mai toccato un mouse in vita sua.

Lavoro nel digitale da oltre quindici anni e sono stato uno dei primissimi utilizzatori di smartphone e tablet, innamorato a prima vista di tutto ciò che è tecnologico, sin dai tempi del Commodore 64. La mia posizione professionale, in termini di “misurazione di qualsiasi cosa sia digitale”, mi ha permesso di mettermi in contatto fin da subito con team di sviluppatori di mobile app e, in base all’analisi dei vari progetti e alla misurazione dei risultati e di come questi cambiavano a seconda delle strategie e delle modifiche adottate, sono riuscito ad acquisire un forte bagaglio di esperienza, sia in termini di idee, sia di usabilità e, soprattutto, a comprendere i differenti ritorni sull’investimento di svariati progetti.

Figura I.1 – Mio papà, con l’iPad regalatogli per i suoi 80 anni, il primo strumento digitale della sua vita.

Gli amici e i parenti sanno a grandi linee quello che faccio per sopravvivere e, praticamente, ciascuno di loro pensa di avere l’idea per l’app di successo. Di volta in volta mi costava (e mi costa) molto tempo e molta fatica spiegare che non è tutto così semplice e immediato ed evidenziare il principale problema di ciascuna idea: spesso esiste già ciò che hanno immaginato, in diverse forme e con sistemi molto più completi. Ho quindi pensato questo libro per loro, per chiunque abbia un’idea per sviluppare un’applicazione. Siamo ormai tutti forti utilizzatori dei dispositivi mobili e ogni persona ha delle passioni: chiunque può quindi avere un’idea vincente nel proprio campo di interesse, non solo gli sviluppatori o i geek come l’autore (mia madre mi propone spesso app in ambito domestico e culinario).

Per questi motivi ho cercato di creare non un manuale di codice e di interfacce, ma un libro che riesca a spiegare la strategia da adottare per creare un’applicazione di successo e che sia utile per tutti. Per chi, essendo un grafico, sa disegnare benissimo le interfacce e non vede l’ora di pubblicare il proprio videogioco, per chi, programmatore col pallino del meteo, che costruisce algoritmi complessi e vorrebbe realizzare il sogno dell’app meteo più precisa al mondo, e per chi, manager che lavora in questo settore o nel marketing e comunicazione di qualsiasi azienda, che quando parla coi grafici e i programmatori capisce meno che non parlando con un mercante arabo in un souk di Marrakech.

Ho scritto questo libro per spiegare a chiunque quanto lavoro ci sia dietro a una semplice icona di un centimetro per un centimetro e come sia complesso, ma anche avvincente e creativo, il lavoro che svolgo quotidianamente. Voglio far capire quante persone e quali conoscenze vi siano sul campo per sviluppare un progetto completo che abbia qualche probabilità di successo.

In un mondo dove chi non lavora nel digitale pensa che siamo tutti Zuckerberg, che sia molto semplice e veloce qualsiasi processo e che non abbia bisogno di un’attenta analisi prima, durante e dopo il lancio del prodotto finale.

Questo libro è rivolto quindi a chiunque abbia avuto un’idea e voglia capire meglio con chi e come potrebbe svilupparla, ma anche a quelli che sono rimasti folgorati dal proprio smartphone, per chi lancia diverse app quotidianamente e ha passato ore su Angry Birds o a sfidare gli amici a Ruzzle e a chi, anche solo per curiosità, vuole comprendere meglio questo mondo.

Per comprendere appieno il fenomeno delle app, vi consiglio di leggere il libro in modo lineare; potete comunque partire da ogni capitolo o saltarne alcuni a piacimento a seconda dei vostri interessi principali e delle vostre conoscenze attuali: se siete grafici, vi consiglio di leggere tutto tranne le parti delle interfacce, sulle quali probabilmente avete una conoscenza già molto approfondita e così via.

All’inizio del libro ho voluto introdurre il mondo delle applicazioni con dei cenni storici sulla nascita dei dispositivi mobili moderni e sugli store; un po’ di numeri per far comprendere la dimensione del mercato. Successivamente, ho cercato di chiarire a tutti la differenza tra applicazioni vere e proprie e web app (o m-site), affrontando il tema di chi, avendo un sito Internet, debba renderlo fruibile e disponibile anche all’utente che naviga in mobilità o, staticamente, ma attraverso un dispositivo mobile. Poiché il traffico di Internet attualmente è già caratterizzato da oltre una visita su tre da dispositivo mobile, è fondamentale adeguare la propria presenza in rete per cogliere le opportunità offerte dai device mobili e dal loro utilizzo in mobilità, che presentano dei tassi di conversione fantastici rispetto al classico sito web accessibile da desktop.

Figura I.2 – L’applicazione di Twitter e la web app di Twitter: sono due cose distinte.

Quindi si entrerà nel vivo delle applicazioni, partendo dall’idea e cercando di comprendere come tradurre un’intuizione in un vero e proprio progetto digitale. Successivamente, parlerò della creazione tecnica di un’app, sia da un punto di vista grafico, sia da quello della programmazione, ma cercando di permettere a chiunque di comprendere questi concetti fondamentali, anche solo per dialogare con i professionisti del settore e trasmettere loro correttamente le informazioni e i risultati che vorremmo ottenere. Nasce da qui l’esigenza di paragrafi come “Cose da sapere… anche se non sei un grafico” e, specularmente, “Cose da sapere… anche se non sei un programmatore”. In seguito, affronteremo i modelli di business che offre il mercato e quale di questi la vostra app potrebbe seguire, analizzando in modo specifico e particolare il tema di come guadagnare dalle applicazioni distribuite gratuitamente, anche attraverso l’utilizzo della pubblicità lato “editore”. Parleremo poi del momento della sottomissione dell’app nello store e di quali siano i dettagli a cui prestare attenzione.

Parleremo del marketing delle applicazioni e di tutti gli strumenti disponibili attualmente sul mercato per dare supporto al lancio della vostra idea, cercando di affermarsi in questi mercati sovraffollati e di come l’utilizzo di tutte le piattaforme digitali possa essere determinante per il successo di un’applicazione.

Infine, affronteremo in modo approfondito, in quanto determinante, i temi della misurazione delle applicazioni, sia in termini di App Analytics, ovvero di misurare e comprendere come gli utenti utilizzano il vostro software e capire quali e quanti miglioramenti si possano apportare nell’ottica del processo di miglioramento continuativo, sia in termini di App Store Analytics, per capire come, misurando gli store stessi, si possano ottenere diverse informazioni sulla propria app e su quelle dei concorrenti.

In chiusura, cercherò di dare delle indicazioni personali sulle evoluzioni del futuro (in realtà già del presente) delle app e della sensoristica, con il cosiddetto “Internet of things” che i dispositivi mobili renderanno diffuso e reale come mai prima.

Tutto il libro è corredato da casi studio reali o, dove non fosse possibile, ipotetici, in modo che si possa comprendere meglio la teoria quando questa viene applicata alla realtà. Spero di potervi appassionare all’argomento attraverso queste pagine e ringrazio chiunque vorrà esprimere un giudizio positivo o negativo al riguardo insultandomi o lodandomi liberamente anche su Twitter, dove mi trovate come @Zanzottera.

Buona lettura a tutti, ma soprattutto buona lettura a te, Jules, a cui dedico questo libro che quando leggerai sarà ormai preistoria, ma tuo papà l’ha scritto per te…

CAPITOLO 1

IL MONDO DELLE APPLICAZIONI

L’evoluzione dei dispositivi mobili

“Capitano Kirk chiama astronave madre”[1]; questa frase è il simbolo della realizzazione di un sogno da parte dell’umanità: mettersi in contatto con altre persone, ovunque siamo e in qualunque momento. Ciò che sembrava mera fantascienza diventò realtà il 3 aprile del 1973, quando Martin Cooper, direttore della divisione Ricerca e Sviluppo di Motorola, fece la prima telefonata da un prototipo di cellulare, passeggiando per le vie di New York[2].

Ci vollero però altri dieci anni e solo nel 1983 Motorola lanciò sul mercato americano il Dyna-TAC 8000x, il primo cellulare prodotto in serie. Più che un telefonino, un “telefonone” dal peso di quasi un chilogrammo (790 g), alto 28 cm (e altri 15 cm di antenna flessibile ricoperta di gomma), autonomia di 60 minuti in chiamata e ricarica in 10 ore, il tutto a soli 4.000 dollari (del 1983).

Figura 1.1 – Il Dyna-TAC 8000x: il primo cellulare prodotto in serie.

I dispositivi mobili si sono diffusi rapidamente a livello globale, superando addirittura il numero dei dispositivi fissi: la comunicazione verbale e scritta (tramite gli sms, altra scoperta recente del 1992[3]) esce dagli uffici e dalle abitazioni; l’uomo raggiunge il sogno dell’ubiquità, perlomeno verbale, sempre che il suo cellulare abbia campo.

Parallelamente alla diffusione dei cellulari, anche Internet si espande a macchia d’olio e sono sempre più gli utenti, le aziende e le organizzazioni che si connettono alla rete e la utilizzano come canale di comunicazione. In pochissimi anni nuovi strumenti di lavoro e personali si affermano e stravolgono molti settori del mercato, accelerando i rapporti e permettendo una comunicazione sempre più efficiente: la posta elettronica e il browser, da perfetti sconosciuti, diventano indispensabili e insostituibili.

Nel 1996, Nokia fa un ulteriore passo avanti, rendendo disponibile la mail e la navigazione via Internet da cellulare con il modello Nokia 9000 Communicator, attraverso la prima rete GSM al mondo, la finlandese Radiolinja.

Mentre i servizi di posta elettronica, simili a quelli della messaggistica già presente sui dispositivi mobili dell’epoca, vennero “traslati” con facilità, mantenendo la medesima usabilità da pc/desktop a dispositivo mobile, la navigazione su Internet attraverso i telefonini è sempre stata un’impresa ardua, molto “da ingegneri” ed estremamente costosa. La prima azienda che capì come migliorare, anche solo parzialmente, semplificando le operazioni, ma soprattutto permettendo l’uso della mail e del web senza costi aggiuntivi, in tutto il mondo e attraverso la propria rete dati, fu la canadese Research In Motion (RIM) che realizzò nel 2003 il primo Blackberry. Ancora oggi RIM, pur vivendo una fase molto complessa e delicata, è molto apprezzata nei Paesi emergenti proprio per la gratuità di questo tipo di servizi.

Fino al 9 gennaio del 2007[4], i cellulari erano progettati per fornire essenzialmente due servizi: telefonate e sms. Le innovazioni del prodotto avevano puntato soprattutto alla riduzione del peso e al prolungamento della batteria: gli schermi rimanevano sempre molto piccoli, spesso con risoluzioni “preistoriche” e colori, se esistenti, in stile videogiochi anni ‘80. L’interazione rimaneva sempre identica: attraverso il tastierino e, nei casi di maggiore “innovazione interattiva”, con l’introduzione di una tastiera qwerty; purtroppo, in questi casi i telefonini più interattivi iniziavano ad assumere dimensioni e pesi ingombranti, come nel caso della serie Communicator di Nokia. I cellulari continuavano a mantenere più o meno la stessa tecnologia hardware, gli stessi design e miniaturizzazioni più o meno discutibili.

Quello che pochi avevano capito, in realtà, era il fatto che ormai chiunque aveva sempre con sé un oggetto con il quale interagiva moltissimo e quotidianamente. Solo una mente geniale come quella di Steve Jobs comprese, prima di tutti, questi aspetti, introducendo un design pulito e accattivante, un nuovo modo di interagire (touch), una durata della batteria straordinaria e soprattutto qualcosa che fosse realmente intelligente, veramente “smart”, più simile a un personal computer che non a un telefonino, che contenesse tutto lo stato dell’arte della tecnologia dell’epoca: accelerometro e GPS in primis. Le chiamate e gli sms sono solo alcuni fra i servizi, insieme a tanti altri, resi disponibili dall’invenzione dell’iPhone.

Il 2007 fu quindi l’anno che segnò la rivoluzione: Apple comprese benissimo gli aspetti dei costi e della disponibilità di banda e creò delle partnership direttamente con gli operatori telefonici, per abbattere sia il costo della connettività, sia quello dell’hardware stesso, con l’introduzione di abbonamenti flat con traffico Internet e iPhone stesso compresi.

Il “melafonino” è stato uno dei più clamorosi successi tecnologici di tutti i tempi: oltre 200 milioni di iPhone venduti, 72 milioni solo da gennaio a giugno del 2012, un successo in grado di vendere oltre 1 milione di unità in sole 24 ore ogni volta che viene lanciato il modello successivo.

L’iPhone, in pochissimo tempo, ha radicalmente cambiato l’utilizzo e il rapporto persona-cellulare, perché viene ormai utilizzato alla stregua di un vero e proprio computer; anzi, possiamo dire che l’iPhone è stato, dopo decenni, il primo vero personal computer.

Steve Jobs ha avuto il merito di anticipare il mercato, comprendendo le esigenze delle persone e le loro abitudini meglio di chiunque altro, facendo nascere delle necessità e delle esigenze prima inespresse, come solo i veri visionari possono riuscire a fare. Se a ciò aggiungiamo il senso estetico per il design e la comprensione profonda di come cavalcare i trend del mercato, le mode e gli status symbol, si comprende meglio questo enorme successo.

A dimostrazione del fatto che ormai i cellulari non sono più solo dei telefoni, la nascita degli smartphone ha portato sul mercato una serie di aziende che non erano produttori storici dei primi dispositivi mobili. Aziende leader nella produzione di telefonini come Ericsson, Motorola e la stessa Nokia hanno subito, e stanno subendo, dei fortissimi contraccolpi da parte di nuovi player, come Samsung e HTC.

I veri motivi del declino repentino dei vecchi protagonisti del mercato sono legati in modo particolare al sistema operativo e alle interfacce. Il sistema operativo dominante sul mercato fino a pochi anni fa era Symbian della Nokia, eccellente all’inizio, quando i telefoni dovevano telefonare e mandare sms, ma molto limitante e quasi assente a livello di strumenti che permettessero a sviluppatori esterni di creare servizi su quel sistema operativo. Questo avveniva perché Symbian non era stato progettato in questo senso. Il sistema iOS fu pensato fin dall’inizio con un ambiente di sviluppo (SDK) accessibile praticamente a chiunque ed estremamente flessibile.

Un’altra azienda che immediatamente comprese l’importanza del sistema operativo per il successo di un cellulare è stata Google. L’azienda di Page e Brin nel 2008 rilascia sul mercato la prima versione di un nuovo sistema operativo per dispositivi mobili (e non solo): Android. La novità, in questo caso, consiste nel volersi aprire ancora di più agli sviluppatori e ai produttori hardware di telefonia: Android nasce come sistema operativo open source, il cui codice è quindi aperto a qualsiasi sviluppatore e produttore di hardware e libero dal pagamento di royalties per il suo utilizzo. Google comprese di essere in estremo ritardo rispetto ad Apple nel settore mobile e capì immediatamente quanto una sua “esclusione” a livello di sistema operativo potesse essere rischiosa. Per questo, l’azienda di Mountain View fu la capofila dell’Open Handset Alliance e decise di offrire gratuitamente a tutti i produttori hardware il proprio sistema operativo, permettendo l’ingresso appunto di nuovi player, come HTC e Samsung, fortissimi a livello hardware ma deboli nel software.

Steve Jobs, invece, pensò a un oggetto che fosse ricco di sensori e di funzionalità, con le capacità di calcolo simili a un computer e un’interazione molto intuitiva, attraverso il touchscreen e l’accelerometro: lo stupore suscitato nel vedere lo schermo adattarsi a seconda dell’orientamento del telefono, ora considerata una cosa normale, fu una delle armi vincenti dei primi iPhone.

L’integrazione del touchscreen è stata rivoluzionaria per quanto riguarda la rapidità di diffusione dovuta alla sua semplicità di utilizzo. Steve Jobs, che aveva il desiderio di rendere lo smartphone, tecnicamente molto avanzato e complesso, uno strumento di facile utilizzo, ha ben pensato di integrare una funzionalità tipica di un altro strumento, il navigatore satellitare. Quest’ultimo infatti è praticamente privo di pulsanti e si imposta utilizzando le icone sullo schermo. In primo luogo, questo metodo di utilizzo lo rende molto più semplice: le icone infatti permettono un utilizzo molto più intuitivo rispetto ai bottoni. Esattamente come il TomTom[5], può essere utilizzato da un manager così come da un camionista (ovviamente senza nulla togliere a quest’ultimo!). Quindi Steve Jobs, la cui necessità era di fare uno smartphone molto semplice da utilizzare in modo che potesse entrare nelle tasche anche dei meno esperti, ritenne che comandare il telefono attraverso il finger touch potesse essere la via per rendere lo smartphone più intuitivo e a prova di utente inesperto. Tutti conosciamo il successo ottenuto dall’iPhone; è quindi superfluo dire che la sua intuizione si rivelò geniale.

Apple comprese immediatamente che aveva creato uno strumento estremamente flessibile e realmente smart, pronto a erogare servizi di ogni tipo. Nasceva quindi l’esigenza di creare un vero e proprio mercato di distribuzione di servizi; Apple c’era già riuscita nel settore della musica, con la sua piattaforma iTunes e, proprio con un aggiornamento di questo software, il 10 luglio del 2008, rese disponibile anche l’Apple App Store. Il giorno seguente veniva presentato l’iPhone 3G a livello mondiale, con l’accesso all’app store precaricato nel dispositivo mobile. L’App Store di Apple venne creato per permettere a una community di sviluppatori di creare software per le più svariate finalità e offrirle quindi a un mercato di milioni di persone a livello globale.

Breve storia degli app store

Gli app store risultano essenziali per l’evoluzione e lo sviluppo anche degli smartphone, in termini di vendite e utilizzatori: un telefono intelligente ha bisogno delle applicazioni per esprimere la propria intelligenza; per questo motivo, il mondo delle applicazioni e i relativi mercati di distribuzione ricalcano quasi perfettamente i sistemi operativi presenti nei vari dispositivi mobili. Apple ha lanciato il suo app store nell’estate del 2008, Google ha lanciato il proprio Android Market nel marzo del 2009 e tre anni dopo lo store è stato ribattezzato Google Play. Research In Motion ha inaugurato il proprio Blackberry App World nell’aprile del 2009, mentre Nokia è proprietaria dell’Ovi Store, inaugurato nel maggio del 2009; Microsoft ha inaugurato il proprio Windows Phone Marketplace nell’ottobre del 2010.

Il mondo delle applicazioni sta attirando altre aziende, che vedono un ambiente molto interessante per fidelizzare la propria audience: in questo senso Facebook stesso ha lanciato, nel maggio del 2012, il proprio store, che è multi-piattaforma, non legato a un singolo sistema operativo e molto integrato con le altre funzionalità del social network più utilizzato al mondo. Anche Samsung a breve entrerà in questo mercato, forte del fatto di produrre non solo smartphone e tablet, ma anche televisioni o, meglio, connected tv.

Il futuro delle app sta persino nei nostri salotti, anche se dovranno essere differenti e adattarsi al contesto della fruizione dell’utente (difficilmente vedremo un’app in una connected tv che ci fornisce indicazioni stradali).

I numeri che realizzano gli store, in termini di fatturato e di diffusione, sono in costante crescita, a testimonianza del potenziale che hanno le mobile application.

In termini temporali, i successi ottenuti dalle app sono stati molto veloci: l’Apple Store, per esempio, è stato lanciato nel 2008 e 5 anni dopo (estate 2013) le applicazioni presenti erano già oltre un milione e quelle scaricate oltre 50 miliardi. Questi numeri hanno fruttato qualcosa come 10 miliardi di dollari ai developer. Nel solo mese di dicembre del 2013 sono state scaricate oltre 2 miliardi di app dall’Apple App Store, che ha pagato oltre 1 miliardo di dollari agli sviluppatori… un bel regalo di Natale.

Il mercato è sano e in crescita, la tendenza alla mobilità è sempre più reale e percepita e la grande diffusione dei device mobili rappresenta uno scenario allettante per chi volesse inserirsi con la propria idea. Basta solo accertarsi che il progetto abbia tutte le caratteristiche richieste dalle mobile application per avere potenzialmente successo.

Numeri e mercati attuali

Per renderci conto della grandezza del mercato in cui stiamo operando, conviene vedere un po’ di numeri che sono stati realizzati dagli store.

Vediamo, dunque, i dati relativi a ogni singolo app store, partendo dal più diffuso: quello di Apple.

Considerando che nel 2012 Apple ha dichiarato di aver venduto più smartphone e tablet che computer desktop, la quantità di iPhone nelle tasche degli utenti è sorprendentemente lievitata negli ultimi mesi.

L’App Store di Apple è presente in 155 Paesi nel mondo (dopo l’ultima estensione che ha aggiunto 32 Paesi). Le applicazioni in vendita al suo interno sono oltre un milione per iPhone e iPod e 500.000 native per iPad[6].

A livello mondiale, secondo Gartner, le applicazioni mobili scaricate fino a oggi sono oltre 45 miliardi. Numeri davvero impressionanti, se li relazioniamo anche al singolo utilizzatore.

Secondo queste stime di Gartner, lo Store di Apple rappresenta circa un quarto dell’intero mercato delle mobile application in termini di download: degli oltre 81 miliardi di app scaricate nel 2013 in totale, circa il 90% risulta essere di applicazioni gratuite. È un dato preoccupante? L’utenza predilige applicazioni gratuite ma… il nostro guadagno allora dove sta? Non vi preoccupate, non è un dato che dovrebbe spaventare, perché ci sono modelli di business alternativi a quello della vendita e ormai quasi sempre il guadagno viene spostato non nella fase di acquisto iniziale, ma in quella del cosiddetto “in-app purchase”, che approfondiremo meglio più avanti. Molto brevemente: l’applicazione viene scaricata gratuitamente e può fruire di una quantità di contenuti limitati in svariati modi; se volete avere accesso a tutte le funzionalità dell’app dovete acquistare differenti pacchetti aggiuntivi, ma dopo avere provato e testato la qualità del software. Questa è una modalità che esiste da decenni nel mondo del software con il sistema del cosiddetto “prova e compra”[7]. Facciamo un esempio nel settore dei videogiochi: Home Design di Teamlava è un’applicazione scaricabile gratuitamente; si inizia a giocare costruendo la propria abitazione, l’app poi invia delle notifiche per proporre l’acquisto di “gemme” utili per continuare a costruire la propria casa. L’utente ha modo di testare il gioco e di capire il livello del proprio gradimento. Quelli più ingaggiati, a cui piace proprio l’idea e il suo sviluppo, per pochi dollari possono comprare delle quantità di gemme che permettono di sbloccare i livelli successivi di difficoltà. Quindi chi ama questo gioco non ci pensa due volte e procede all’acquisto.

Bisogna sottolineare come il processo di acquisto sull’Apple Store sia molto immediato e impulsivo: il sistema ha già memorizzato il numero della carta di credito che serve per attivare un account completo nella piattaforma Apple e, con un paio di clic, si conferma l’acquisto e si continua a giocare. Come vedremo poi in seguito, questo modello di business è fortemente condizionato da una positiva “user experience” in quanto l’utente fa l’in-app purchase solo se l’app che sta utilizzando lo soddisfa realmente!

Quindi, dei circa 81 miliardi di app scaricate dagli app store, abbiamo visto che nove su dieci sono gratuite, mentre i restanti 5 miliardi sono quelle “low cost”; sempre dai dati Gartner vediamo come l’87% delle app scaricate a pagamento abbia un prezzo inferiore a 3 dollari.

Tabella 1.1 – Previsioni di download di applicazioni a livello mondiale (dati in miliardi). Fonte: Gartner.

Figura 1.2 – Previsioni di download di applicazioni a livello mondiale (dati in miliardi). Fonte: Gartner.

I dati dell’Apple Store hanno decisamente, per il momento, maggior peso rispetto a quelli degli altri mercati. Il motivo è da ricercare nella maggiore semplicità di sviluppo: infatti il sistema iOS risulta essere molto meno frammentato rispetto a quello di Android e a quelli degli altri concorrenti, quindi gli sviluppatori prediligono questo sistema operativo. Inoltre, abbiamo visto i dati di diffusione dell’hardware e così comprendiamo i motivi della disparità tra i dati di un market e l’altro. Infine, l’utilizzatore medio dei prodotti Apple ha una capacità e propensione di spesa molto più alte rispetto a quelle di altri sistemi operativi: l’utente Apple è un forte consumatore di digitale e con una buona capacità di reddito, e questo permette di considerare l’acquisto di un’applicazione alla stregua di un caffè.

Ultima, ma non meno importante, è la propensione alla pirateria digitale degli utenti delle differenti piattaforme: il mondo Apple è molto chiuso e protetto in tal senso, mentre per l’ambiente di sviluppo Android esiste un “mercato nero” di applicazioni disponibili nei circuiti peer to peer più noti, come Torrent ed eMule; in tal senso gli sviluppatori di app in vendita, che non utilizzano modelli di business alternativi rispetto alla vendita diretta e immediata dell’app, trovano immediatamente disponibile il proprio software condiviso su queste piattaforme.

I due attori principali del mercato, come abbiamo già visto, sono Apple e Google. Dal punto di vista dell’hardware, Android è il più diffuso: secondo ComScore[8], raggiunge il 50% delle quote di mercato, contro il 31% di iOS. In termini di applicazioni, invece, i numeri maggiori li fa Apple.

Innanzitutto, Apple batte Android già solo nella percentuale di app sviluppate per l’uno o per l’altro sistema: infatti circa il 60%[9] delle app sono per iPhone, mentre solo il 40% per Android.

Perché questa netta differenza d’interesse da parte degli sviluppatori per le due piattaforme? Una motivazione è il dominio esercitato nei tablet, dove l’iPad di casa Apple ha generato l’88% delle sessioni legate alle app nei primi cinque mesi del 2012. Staccatissimi, il Galaxy Tab di Samsung (con il 9%) e il Kindle Fire di Amazon (con il 3%). A supporto di questo dato, anche l’eccessiva frammentazione del sistema Android, a fronte della grande semplicità di programmazione del sistema concorrente di Apple. Un altro fattore che favorisce lo sviluppo in ambiente iOS è legato alla diffusione dei tablet, dove l’iPad figura da grande padrone[10] contro i competitor di casa Samsung o Amazon:

Figura 1.3 – Numero di Download di applicazioni iOS vs Android e comparazione tra il fatturato generato dall’Apple App Store e quello di Google Play[11]. Fonte: App Annie Intelligence.

Nel secondo trimestre del 2013, la piattaforma di Google ha superato quella di Apple in termini di download assoluti, ma questo aspetto non deve necessariamente influenzare le scelta per lo sviluppo: se passiamo infatti all’analisi del fatturato generato da questi download di app, vediamo come l’App Store di Cupertino presenta ancora oggi delle performance molto più interessanti in termini di guadagni reali per coloro i quali sviluppano e mettono in pratica idee digitali su questa piattaforma. Tutto ciò a riprova degli assunti precedentemente elencati in termini di dominio degli store. La partita è ancora aperta: Google deve risolvere i problemi di frammentazione e contemporaneamente mantenere solido il rapporto con i propri partner produttori di hardware, ancora di più oggi che la società di Mountain View è entrata in questo business dopo l’acquisizione di Motorola. Apple, dal canto suo, sta perdendo progressivamente il proprio appeal innovativo e rivoluzionario, forse troppo legato alla personalità di Steve Jobs. La casa di Cupertino deve recuperare in innovazione e seguire una politica dei prezzi che mantenga il livello di brand e di status symbol del prodotto e che, contemporaneamente, riesca a spostarsi verso segmenti più bassi, come sta già facendo. Infine, la scheggia impazzita del futuro di questa vera e propria battaglia per il predominio dei sistemi operativi dei dispositivi mobili potrebbe essere Microsoft: la casa fondata da Bill Gates non è abituata a inseguire i competitor e per la prima volta si trova a doverlo fare. Microsoft ha già commesso, dal mio punto di vista, degli errori alquanto grossolani attendendo un po’ troppo alla finestra e sottovalutando il fenomeno degli smartphone, pensando che questi non potessero sfociare nei tablet che stanno erodendo considerevoli quote di mercato al segmento dei personal computer. Ultimamente, però, la casa di Palo Alto sembra aver preso il problema sul serio e, dopo avere creato una partnership molto vantaggiosa con Nokia, è arrivata ad acquisire il brand storico, leader e produttore di miliardi di cellulari, in un momento molto critico della sua storia: due imperi in declino si uniscono per combattere nuove potenze rivoluzionarie e innovative.

In Google Play, all’inizio di dicembre del 2013, erano presenti 875.721 applicazioni[12]: statistica aggiornata praticamente in tempo reale da parte di AppBrain.

Figura 1.4 – Numero totale di applicazioni presenti su Google Play. Fonte: AppBrain.

Lo sviluppo del numero di applicazioni su questo mercato è in continua e inarrestabile crescita. Oltre una applicazione su cinque (al mese di dicembre del 2013) viene considerata e definita in termini di bassa qualità, “low quality”; queste sono le app che Google periodicamente rimuove dal mercato, diminuendo così il numero di software disponibili a vantaggio della qualità, appunto.

Figura 1.5 – Numero di applicazioni gratuite e a pagamento presenti in Google Play. Fonte: AppBrain.

Delle quasi 900.000 app presenti in Google Play, solo il 19% è a pagamento, mentre il restante 81% è gratuito (completamente free o free con in-app purchase).

Nel grafico della Figura 1.6 vediamo la distribuzione delle app secondo la categoria di prezzo. Osserviamo con attenzione le app a pagamento nel negozio di applicazioni della casa di Mountain View all’inizio di dicembre del 2013: vediamo come le app di maggiore successo siano distribuite nelle categorie free e in quelle con un prezzo unitario molto basso; esiste comunque uno spazio di successo tra i 5.000 e i 50.000 download, con un ampio numero di software che hanno raggiunto questi obiettivi. Anche questo mercato pay è comunque vivo, bisogna solo avere l’idea giusta, la corretta strategia e il supporto alla distribuzione delle app.

Nel momento in cui state decidendo se rilasciare la vostra app gratuitamente, oppure prevederne un costo di vendita, bisogna analizzare lo stato del mercato nel quale vi state affacciando e vedere, ove possibile, di perseguire modelli di business alternativi a quello della vendita diretta.

Se passiamo a un’analisi a livello di categorie, invece, la più popolata in Google Play a inizio dicembre del 2013 risulta essere quella generica dell’entertainment, che ha quasi 90.000 delle app complessive; poco più di 75.000 sono invece le mobile application della categoria Personalization. Le altre categorie scendono a cascata come si vede dal grafico della Figura 1.7.

Figura 1.6 – Distribuzione dei download delle app per prezzo. Fonte: AppBrain.

Figura 1.7 – Distribuzione delle app di Google Play nelle 10 categorie top. Fonte: AppBrain.

Un altro mercato è il Windows Phone Marketplace, che al momento presenta 146.930 mobile application per i dispositivi Windows. Ricordo che il mercato delle app sviluppate per gli smartphone Windows è nato alla fine del 2010, per cui il tempo in cui esso è presente sul mercato è minore rispetto agli altri. Del totale delle applicazioni, il 75% è free, l’11% è rilasciato in modalità trial, e successivo pagamento, mentre il 14% sono app a pagamento[13].

Microsoft sta cercando in tutti i modi di colmare la distanza che si è creata rispetto ai due top player dei sistemi operativi mobili, prima con una partnership molto vantaggiosa con Nokia nel febbraio del 2011 e, successivamente, andando ad acquisire il marchio scandinavo, ormai in crisi per l’avvento degli smartphone, con una mossa, dal mio punto di vista, molto intelligente. Nokia è tuttora uno dei principali leader nell’hardware dei dispositivi mobili (ricordiamo tantissimi dumbphone di enorme successo) mentre Windows chiaramente si occupa della parte software. L’azienda fondata da Bill Gates, nel bene o nel male, è ancora leader a livello di sistemi operativi desktop e per il pacchetto software di lavoro generico montato su milioni di computer: Office. Questi due fattori non sono da sottovalutare nella battaglia dei dispositivi mobili, dove la sincronizzazione dei documenti sul cloud e la loro rielaborazione e consultazione da qualsiasi dispositivo, anche in mobilità, sono funzionalità che possono creare dei vantaggi competitivi importanti, soprattutto per gli utenti non “power users”, ovvero coloro che hanno un desktop per lavoro, ma non lavorano nel digitale e hanno una conoscenza media dei mezzi, pur utilizzandoli. Windows potrebbe avvantaggiarsi della sua posizione dominante per rendere tutto più semplice, fluido, automatico e senza punti di discontinuità.

Inoltre, se ragioniamo a livello globale, la battaglia delle nuove generazioni di dispositivi mobili è solo all’inizio, perché la penetrazione degli smartphone rispetto ai “feature phone” (che personalmente preferisco chiamare dumbphone) nei Paesi emergenti è ancora molto bassa: nei Paesi del BRIC[14] l’utilizzo dei nuovi dispositivi mobili è ancora bassissimo e il marchio Nokia è molto forte proprio in queste nazioni come in tutte le altre economie emergenti; non vi è quindi ancora una forte fidelizzazione del consumatore finale al “melafonino” o alla “galassia” Samsung. Sostanzialmente in questi Paesi si devono ancora aprire le danze e i giochi sono ancora tutti da fare. Infine, anche Nokia sta facendo la sua parte: il modello Lumia è un dispositivo mobile dall’hardware eccezionale: la sua telecamera è praticamente la migliore sul mercato e questo modello, anche grazie a una politica molto aggressiva, viene offerto sul mercato col migliore rapporto qualità/prezzo esistente. Ultimissimo fattore da non sottovalutare in ottica BRIC è la possibilità dell’utilizzo di uno dei migliori navigatori satellitari al mondo (le mappe Navteq di Nokia sono tra le più aggiornate e complete a livello globale) anche senza la connettività: aspetto importantissimo per tutti i mercati dove il prezzo e il costo della connettività 3G non sono ancora bassi, perlomeno in rapporto al salario medio, e per tutti coloro che si spostano di frequente e che non possono permettersi l’utilizzo del roaming a causa delle tariffe assurde ed esorbitanti che ancora esistono.

Nel grafico della Figura 1.8 vediamo la suddivisione delle applicazioni della multinazionale di Palo Alto per categoria; anche in questo caso si può notare come la categoria più numerosa risulti essere quella del divertimento.

Figura 1.8 – Distribuzione delle app di Windows Phone Marketplace nelle categorie top. Fonte: Windows Phone app List.

Le app dell’entertainment, con il 17% del totale, sono le più offerte e riscuotono maggiore successo. I tool e le app dedicate alla produttività rappresentano il 14% del totale e il 14%, invece, sono giochi. A cascata seguono tutte le altre categorie.

Prima dell’acquisizione da parte di Microsoft, le app sviluppate per gli smartphone Nokia[15] erano disponibili sull’Ovi Store. Il market delle app per i Nokia non è mai realmente decollato: nonostante un elevato numero di telefonini che potenzialmente potevano usufruire del servizio, il numero di download è stato sempre bassissimo: gli utenti Nokia erano persone che usavano il telefonino per le sue due funzioni di base: telefonare e inviare sms; non erano ancora pronti all’utilizzo delle app. L’Ovi Store, al momento della sua definitiva chiusura nel 2013, era popolato da circa 120.000 applicazioni. Sul sito dedicato ai developer Nokia, la compagnia dichiarava di avere oltre 17 milioni di download giornalieri che, evidentemente, non sono bastati a sorreggere tutto l’ecosistema.

Per quanto concerne infine la RIM, azienda produttrice del Blackberry, parliamo di una storia con un’ascesa velocissima e un’altrettanta rapida scomparsa di questo marchio; tutto ciò a dimostrazione di come il mercato dei dispositivi mobili sia estremamente fluido e in continuo e rapidissimo cambiamento e come siano sostanzialmente i consumatori che, spostandosi in massa verso nuovi brand e nuovi modelli di smartphone, decretano vita e morte delle aziende produttrici. L’usabilità dello strumento e la presenza di un mercato di applicazioni di livello sono degli elementi fondamentali. La breve, ma intensa, storia della RIM è un caso esemplare di come un produttore non comprenda immediatamente come si stiano evolvendo gli utenti e non riesca quindi a dare risposte adeguate a nuove esigenze. RIM ha dominato una nicchia di mercato business della telefonia mobile, grazie all’introduzione della messaggistica istantanea e gratuita a livello mondiale. I produttori di Blackberry non hanno però compreso che anche i propri utenti business avevano bisogno di un browser e di una navigazione Internet dignitosa e dell’intrattenimento. Navigare con un Blackberry era faticoso e rappresentava per l’utente una pessima esperienza, mentre la navigazione con un iPhone o uno smartphone Samsung costituiva una funzionalità primaria in quei modelli di telefoni. Inoltre, la mancanza di giochi e app di intrattenimento all’altezza di quelli presenti nell’Apple App Store o in Google Play ha generato una lenta, ma inesorabile, perdita di utenti a vantaggio delle piattaforme concorrenti; questa “emorragia di utilizzatori” ha avuto un’accelerazione incredibile dopo un problema enorme di RIM sulla propria rete interna: andando in downtime tutta la rete RIM, gli utilizzatori Blackberry di tutto il mondo sono rimasti senza mail, messaggistica e connettività per alcuni giorni. Considerando l’utilizzo business molto elevato a livello mondiale, questo problema tecnico ha lasciato sostanzialmente centinaia di migliaia di manager e agenti commerciali isolati dal proprio lavoro. Le aziende non hanno perdonato a RIM questo problema, trasferendo in massa milioni di utenze business verso le altre piattaforme. Blackberry ha recentemente cambiato politica aziendale, adottando un sistema ibrido, sostanzialmente trasportando applicazioni create per altri sistemi operativi mobili e adattandole al proprio in modo semiautomatico (funzione fondamentale per coinvolgere gli sviluppatori di software). Esiste ancora quindi un piccolo mercato di app per i modelli RIM: il Blackberry World ha cambiato nome da poco, con il lancio dell’ultimo device Blackberry 10, perché prima era il Blackberry App World.

Il market presenta all’incirca 60.000 mobile application per un totale di circa 2 miliardi di download raggiunti nel 2012.

Facciamo un po’ di ordine: differenze tra app e web app/m-site

Prima di scendere nel dettaglio delle applicazioni mobili, cerchiamo di chiarire con maggiore precisione che cos’è una mobile application, rispetto a una web app e anche a un sito sviluppato per dispositivi mobili, detto m-site. Cerchiamo di delineare brevemente vantaggi e svantaggi di questi strumenti simili, ma diversi per potenzialità, distribuzione e complessità di sviluppo.

Vediamo di spiegare in primo luogo che cos’è un’applicazione per dispositivi mobili, che è anche l’oggetto principale di indagine di questo libro: la mobile application è un vero e proprio software che, una volta scaricato e installato, permette un’estensione delle funzionalità native dello smartphone o del tablet. Possiamo tranquillamente paragonarla ai software esistenti per il pc, che permettono di ampliare le funzionalità base dei computer, siano essi software per lavorare e di produttività, ma anche videogiochi, strumenti per la visualizzazione e l’elaborazione di immagini, video e audio, sostanzialmente qualsiasi cosa che possa essere installata su un computer. Quando compriamo uno smartphone (così come avviene per un personal computer), al suo interno sono già installate alcune funzionalità considerate basilari dalla casa madre, come per esempio: il calendario, il client di posta elettronica, un browser, un navigatore satellitare, la fotocamera, la galleria delle immagini e altro ancora. Ognuno di noi poi può ampliare a piacimento le funzionalità del suo device, accedendo allo store di riferimento del sistema operativo e scaricando le app di suo interesse.

Con riferimento alle applicazioni installate di default sui dispositivi mobili e considerando il parallelismo che stiamo facendo con il mondo dei computer desktop, è interessante notare come nessun organo internazionale di monitoraggio della concorrenza abbia ancora definito regole certe e precise in questo ambito. Ricordiamo che per il mondo dei pc c’è stata una lunghissima battaglia legale nei confronti di Microsoft[16], con una delle multe più clamorose mai inflitte da parte dell’Unione Europea, per avere installato di default il proprio browser insieme al sistema operativo. Questo fatto sta succedendo da anni ormai nel mondo dei dispositivi mobili, forse in modo ancora più forte quando si tratta di abuso di posizione dominante, perché l’installazione di un secondo browser negli smartphone è molto minore se paragonata a quella nei desktop. E la battaglia tra sistemi operativi si gioca anche con questi piccoli, ma fondamentali, dettagli (o stratagemmi). Esiste già un precedente molto significativo nelle mappe, utile per capire meglio il meccanismo e i vantaggi nel poter disporre del proprio sistema operativo installato sul dispositivo hardware. Apple inizialmente installava di default su tutti i propri dispositivi l’app Google Maps come navigatore satellitare, decretando sostanzialmente la morte di decine di navigatori satellitari e mettendo in seria difficoltà aziende come TomTom e Garmin. Dopo l’ingresso di Google nel mercato dei sistemi operativi mobili, con la nascita quindi di un agguerrito concorrente, la reazione di Apple fu decisamente aggressiva: oltre a escludere dal proprio board Eric Schmidt, l’allora amministratore delegato di Google, la casa di Cupertino ha cominciato a lavorare immediatamente a un proprio sistema di mappe con relativa applicazione. I risultati si sono visti solo dopo diversi mesi (non è banalissimo mappare il mondo), all’uscita dell’iPhone 5: sul melafonino era scomparso Google Maps, sostituito da Apple Maps. L’esordio delle mappe di Apple fu una tragedia: anche un colosso del software come l’azienda fondata da Steve Jobs ha incontrato delle problematiche serie a livello di usabilità e funzionalità delle mappe. I consumatori, ormai sempre più giudici del mercato, hanno protestato in massa per i disservizi anche in modo molto sarcastico e divertente, postando sui social network e sui blog le migliaia di errori delle Apple Maps[17]; la protesta fu talmente vibrante che, per la prima volta nella storia di Apple, il nuovo amministratore delegato Tim Cook inviò a tutti gli utenti una lettera di scuse, ammettendo che le loro mappe al momento non erano un granché, aggiungendo chiaramente che l’azienda avrebbe investito tantissimo per migliorare il proprio software e, fatto più unico che raro, invitando i propri utenti a scaricare le mappe dei concorrenti, fintantoché anche quelle di Apple non avessero raggiunto uno standard decente. Molti utilizzatori scaricarono le mappe dei concorrenti, ma Apple non si perse d’animo continuando a investire nelle mappe, stringendo accordi con TomTom per la parte software e con Saab[18] per la mappatura a livello globale. Le mappe di Apple sono migliorate di molto, ma l’aspetto più importante per la casa di Cupertino è stato quello di poter installare di default sui propri dispositivi il software di mappe proprietarie[19]. Nel corso di alcuni mesi, l’utilizzo delle mappe Apple è aumentato drasticamente, soprattutto dopo l’introduzione della versione 7 del sistema operativo (cosiddetto iOS 7), tanto che attualmente le mappe proprietarie del melafonino sono più utilizzate rispetto a quelle di Google, nonostante, a mio parere, queste ultime siano ancora più precise ed efficienti. La potenza e la forza dell’installazione di default sono enormi e riscontrabili in questi dati, perché non sempre il software migliore vince, ma vince quello meglio distribuito.

Figura 1.9 – Andamento di utilizzo di Apple Maps vs Google Maps nel corso del tempo. Fonte: Comscore.

Torniamo ora a parlare della distinzione che bisogna avere ben presente a livello concettuale riguardo a ciò che si può realizzare per i dispositivi mobili: ogni applicazione va sviluppata per i diversi ambienti in cui si intende distribuire il proprio software e se lo si vuole diffondere su più device possibili. Se ho intenzione di proporre la mia app su Apple Store e su Google Play, per esempio, dovrò sviluppare due applicazioni per i due diversi sistemi operativi: una per iOS e una per Android. Si può sviluppare l’app singolarmente per ogni sistema operativo in modo cosiddetto nativo, oppure anche per un solo e unico sistema operativo e in seguito, anche attraverso l’utilizzo di software ad hoc, trasformare l’app, rendendola fruibile anche su altre piattaforme con funzionalità, ove possibile, pressoché identiche senza uno sforzo eccessivo in termini di adattamenti. I codici nativi più utilizzati corrispondono chiaramente a quelli dei sistemi operativi dei dispositivi mobili: per il mondo Apple il codice nativo è denominato Objective C, per il mondo Android è Java e, infine per il mondo Windows è .NET. È molto difficile trovare un solo programmatore che sia ferrato in tutti e tre questi codici nativi, meglio quindi comprendere su quali piattaforme e con quali strategie si intende procedere nei vari mercati delle app già in fase di selezione dello sviluppatore o, meglio ancora, dell’azienda che sviluppa app (e anche in questi casi ci sono delle differenti specializzazioni). Il mio consiglio è di chiedere fin dall’inizio in quale linguaggio di programmazione verrà sviluppata la vostra idea e capire bene i vantaggi e gli svantaggi delle diverse soluzioni. Alcuni sviluppatori utilizzano invece piattaforme trasversali di terze parti con un codice proprio o ibrido: esempi molto conosciuti sono Appcelerator, Phonegap, Titanium e moltissimi altri player. Queste piattaforme, ultimata la nostra app nel loro rispettivo linguaggio di programmazione, convertono poi, in modo automatico o quasi, il codice unico sviluppato, in modo che possa funzionare sulle differenti piattaforme presenti sul mercato.

Successivamente, dovrò applicare tecniche di ASO (la SEO per il mondo delle app) precise per ognuna di loro, in quanto le direttive per l’ottimizzazione del posizionamento dell’app sono diverse per ogni mercato: tutto ciò implica una profonda conoscenza di tutti i diversi ambienti; in seguito vedremo come approcciare i mercati e le varie tecniche di ottimizzazione del prodotto.

Le mobile application sono, tra le due soluzioni possibili app o web app/m-site, quelle che riescono di più a sfruttare la sensoristica di bordo degli smartphone e dei tablet e che si integrano maggiormente all’interno del dispositivo mobile. Le app, intese come software, offrono quindi le migliori possibilità, come vedremo successivamente, per rendere il software più funzionale e integrato nel sistema operativo stesso e renderlo più fruibile in mobilità. Le performance e le potenzialità di calcolo delle app, in particolar modo quelle native, sono sempre migliori rispetto alle web app per il fatto che comunicano direttamente con il processore e la memoria dell’hardware, a differenza delle seconde, che hanno come “intermediario” della trasmissione ed elaborazione dell’informazione il browser del dispositivo mobile; sostanzialmente quindi effettuano un passaggio in più rispetto alle app vere e proprie.

Figura 1.10 – L’app di Facebook, una delle più scaricate al mondo.

Parlando della seconda categoria di software fruibili da dispositivi mobili, preferisco fare una distinzione tra web app vere e proprie e m-site. La distinzione non è tecnica, in quanto le due famiglie sono identiche da questo punto di vista, bensì di funzionalità e strategia: un m-site è la trasposizione del contenuto completo o parziale di un website, per renderlo fruibile anche a chi accede da dispositivi mobili, mentre una web app è un insieme di pagine web che forniscono un servizio ben preciso e offrono funzionalità molto simili a quelle delle applicazioni, pur erogandole in modalità browser. È una distinzione molto sottile, che forse non tutti riusciranno a comprendere e su cui forse non tutti sono d’accordo, preferendo distinguere solo le app dalle web app tout court. La web app, parlando anche da un punto di vista tecnico, è sostanzialmente una pagina web scritta in Html5, Javascript e CSS, raggiungibile da smartphone dotato di browser e connesso alla rete. In pratica è una via di mezzo tra la mobile application appena vista e il sito mobile (m-site) che analizzeremo tra poco; essa è sempre composta da una o più pagine web, ma cerca di offrire un servizio interattivo ad hoc per i dispositivi mobili. Presenta delle funzionalità tipiche delle applicazioni in termini di interfaccia utente, user experience e funzionalità, ma non è installata sul device in utilizzo, bensì è residente in rete. Sul dispositivo mobile dell’utente viene memorizzato il link al web dove questa risiede e non il software stesso che funziona e viene elaborato principalmente sul server. Rispetto alla mobile application, quindi la web app, per funzionare deve necessariamente essere richiamata da uno smartphone collegato alla rete; di fatto, è quindi un semplice link a un applicativo remoto, che per essere caricato necessita di connessione Internet. La necessità della connessione ha due implicazioni, una negativa che pregiudica la velocità di risposta: se la connessione o il server remoto sono lenti, il caricamento della web app potrebbe essere a sua volta lento. L’altra è positiva: non dovendo installare l’app direttamente sul device dell’utente, non ci sono più i limiti di peso tipici di altri canali quali appunto le mobile application. Infatti l’app viene scaricata dallo store e installata direttamente sullo smartphone o tablet; deve quindi rientrare all’interno di un determinato peso in termini di KB, mentre la web app, risiedendo su un server, ha a disposizione GB. Ovviamente in caso di connessione lenta, più la web app è pesante, più tempo richiederà per caricare tutti gli oggetti completamente ma, d’altra parte, queste difficoltà sono tipiche anche dei siti Internet.

Per quanto riguarda il posizionamento, invece, la web app segue esattamente le logiche di un sito sviluppato per dispositivi mobili, essendo soggetta quindi solo alle regole dei motori di ricerca.

Infine abbiamo l’m-site, a cui dedicheremo un paragrafo ad hoc, che è la versione mobile del sito Internet fruibile anche da desktop. In questo caso, da anni ormai si parla di responsive design: ovvero il design di una pagina web deve rispondere in modo differente, a seconda della tipologia di dispositivo che carica la pagina stessa: quindi la homepage visualizzata da un computer desktop risponderà a livello di codice in modo differente rispetto a quella visualizzata da uno smartphone e, eventualmente, anche da un tablet. La strategia del “mobile first”, ovvero pensare al proprio sito web considerando in primo luogo l’utente mobile, è forse un po’ eccessiva, se pensata in tutti i settori, ma estremamente utile per alcuni mercati collegati direttamente alla mobilità. Si pensi a chi sviluppa il sito di una società di autostrade o di stazioni di rifornimento di carburante. Personalmente credo che quando si pensa al proprio sito web in ottica mobile, bisogna andare oltre, ove ce ne siano l’esigenza e la possibilità, al concetto di responsive design, per arrivare all’adaptive design e al contextual design: la pagina web non deve semplicemente rispondere in modo diverso, ma deve bensì adattare la propria forma e il proprio contenuto a seconda della tipologia di device che si connette. Deve cercare di comprendere il contesto in cui si trova l’utente, perlomeno in modo indiretto, e adattare il design ripensando il contenuto e la sua distribuzione, e soprattutto offrire funzionalità uniche all’utente con il dispositivo mobile rispetto a quello desktop. E il sito della mia officina di cambio e riparazione gomme, quando viene visitato da desktop, sarà visto in modo diverso rispetto a come verrà visualizzato in una visita da smartphone, in quanto comprenderà il contesto dell’utente in mobilità, attivo delle funzionalità immediate che sono ben evidenti e raggiungibili da uno smartphone. Per i device mobili devo quindi prevedere un pulsante che faccia partire una chiamata direttamente a un numero attivo 24 ore su 24, per qualsiasi emergenza, così come un altro che attivi automaticamente un software di navigazione satellitare con già inserito l’indirizzo esatto dell’officina. Chi userà invece il sito web desktop troverà anche tante altre informazioni come la foto gallery, l’offerta per il cambio e il rimessaggio degli pneumatici invernali, i nomi dei meccanici dello staff e tutte le promozioni attive. L’m-site deve invece offrire le funzionalità base principali. Il vantaggio enorme delle visite di questo tipo al mio m-site è quello che le visite presentano un tasso di conversione enorme rispetto al sito desktop: quando un utente va sul sito dell’officina di cambio e riparazione gomme, molto probabilmente ha appena bucato o sente un rumore strano a una ruota e ha un bisogno urgente e immediato. Comprendere il contesto dell’utente e rispondere in modo pronto e veloce attraverso il proprio sito web, selezionando il contenuto e riducendolo enormemente, è una strategia vincente per chiunque. Quando sono a Bergamo con la gomma dell’auto che fa un rumore strano, vado su Google e cerco: “gomme auto Bergamo”, clicco sul primo risultato, se il sito non è m-site probabilmente si aprirà lentamente, farò fatica a capire dove si trova e come chiamare; torno quindi su Google, clicco sul secondo risultato, risponde un m-site velocissimo con un bel tasto “chiama” e un tasto “mappa”: apro la mappa e l’m-site ha appena guadagnato un nuovo cliente in arrivo, portato direttamente da due pulsanti; il non m-site, primo a livello SEO, perde in usabilità. Non è un semplice fatto di responsive, ma è una strategia adattiva e chi si adatta per primo sopravvive. Le altre specie si estinguono, è una legge darwiniana, sempre valida anche nel mondo digitale: fate una prova nella città in cui siete e cercate un’officina di ricambio gomme (o un autosoccorso stradale), cliccate sui primi dieci risultati di Google: credo che tuttora una metà dei siti web presenti (a esclusione dei portali validi in tutte le province) non abbia nessuna delle banalissime funzionalità sopra riportate e questo potrebbe contribuire alla loro estinzione.

Per rendere più comprensibile la mia personale distinzione tra web app e m-site, faccio un esempio sviluppato personalmente di m-site, con al suo interno una piccolissima web app.

Nell’immagine della Figura 1.11 vediamo come viene visualizzata la homepage del sito di Otto Chocolates, produttore di cioccolato biologico e Fairtrade®, nel quale l’azienda vuole comunicare i suoi otto punti di forza e di differenza rispetto ai concorrenti. Il sito web è pensato con una testata scorrevole, tecnicamente denominata “carosello”, ormai di moda in molti siti web, con un contenuto raggiungibile da menu a tendina verticali per le varie sezioni.

Figura 1.11 – Sito web di Otto Chocolates in versione desktop.

Nella Figura 1.12 vediamo come lo stesso sito si adatta, cambiando in modo abbastanza sensibile sia il layout sia il contenuto: il carosello iniziale resta, più compatto, e viene aggiunta la funzionalità swipe, così che l’utente può scorrere in modo semplice e intuitivo gli otto punti di forza con le relative immagini semplicemente facendo scorrere un dito; viene migliorata quindi l’esperienza dal lato dell’utente, che si ritrova a sfogliare le immagini di un sito web come per qualsiasi app di gestione immagini presente nel suo smartphone. Il contesto si modifica, e devono quindi cambiare le modalità di erogazione del contenuto, emulando il più possibile le funzionalità ormai naturali che l’utente incontra. Inoltre alcune sezioni del sito desktop, come le foto gallery e un video a rotazione, vengono messe in primo piano e sono direttamente visibili dalla homepage: questo perché gli utilizzatori mobile gradiscono spesso guardare immagini e video piuttosto che leggere un testo, anche se breve su uno schermo così piccolo; per questo motivo i contenuti di queste sezioni vengono messi più in rilievo. Inoltre, avendo a disposizione anche un’applicazione gaming gratuita su Apple App Store, questa viene pubblicizzata in modo più invasivo rispetto al sito desktop: compare un piccolo banner pubblicitario del formato classico dell’advertising su dispositivi mobili, che invita l’utente a scaricare l’applicazione. Un m-site è il punto più vicino che si possa avere al download di una propria applicazione, in quanto distante solo due clic dal download. L’app viene chiaramente comunicata anche sul sito desktop, ma con dei banner molto più soft rispetto all’m-site.

Figura 1.12 – M-site di Otto Chocolates.

Infine l’m-site presenta una piccolissima web app al suo interno, raggiungibile attraverso un pulsante ben visibile denominato S.O.S. Cioccolato (Figura 1.13): cliccando, si accede a una pagina web che, grazie al corretto uso dell’Html5, chiede all’utente di segnalare la propria posizione (Figura 1.14) e, una volta ricevuto il consenso, mostra la mappa con i punti vendita più vicini alla posizione dell’utente, dove può trovare la cioccolata Otto Chocolates. Un’operazione di comunicazione e di utilizzo che ha avuto un eccellente riscontro tra gli utenti che stanno utilizzando questa funzionalità: dopo la homepage, questa sezione del sito è la più visualizzata da parte degli utenti dell’msite. Questa piccola web app per smartphone ha senso proprio solo esclusivamente su questi dispositivi e in misura minore sui tablet, mentre non ha assolutamente senso nella versione desktop, dove è presente la classica pagina dei rivenditori sia a livello di mappa visualizzabile e interattiva con la personalizzazione di Google Maps, sia a livello di elenco di punti vendita tabellare.

Figura 1.13 – Il pulsante S.O.S. Cioccolato di Otto Chocolates.

Una delle principali differenze tra app e web app/m-site è certamente quella del canale distributivo. Come già spiegato, l’app è un vero e proprio software che viene scaricato da un app store come unico canale distributivo e viene quindi installato sul dispositivo mobile dell’utente. Una web app invece non viene scaricata, se non al momento della consultazione, e non viene mai installata all’interno del dispositivo, in quanto il software risiede su uno o più server in rete e viene raggiunto attraverso un browser in modo pressoché identico a quello di un sito Internet e, come un sito Internet, può essere raggiunto da un link, da una ricerca (che è comunque un link) o attraverso una richiesta diretta del browser, nel caso in cui abbia messo l’url nei preferiti del browser.

Figura 1.14 – Un esempio di web app: S.O.S. Cioccolato di Otto Chocolates.

Gli smartphone permettono di aggiungere anche una determinata url come icona sul telefono, al pari delle applicazioni scaricate dagli store: questo fatto può generare molta confusione negli utenti meno abili, ma risolve molti problemi a chi deve impostare il tablet per questi utenti meno smaliziati (vero papà?).

Le app sono quindi negli store, mentre le web app vivono nel World Wide web; gli utenti che cercano software per i loro dispositivi mobili partono dagli store e quindi non distribuire il proprio software in questi canali potrebbe significare perdere molte occasioni di acquisizione di utenti; lo sviluppo di un’applicazione deve tuttavia presentare qualcosa in più rispetto a una web app/m-site, perché gli utenti si aspettano un’esperienza diversa quando utilizzano un’app rispetto a quando navigano col browser del proprio dispositivo mobile.

Dal punto di vista del posizionamento, essendo dei siti Internet a tutti gli effetti, le web app e gli m-site sono soggetti all’indicizzazione nei motori di ricerca e alla SEO classica; in un prossimo futuro solo gli m-site saranno ben indicizzati nelle ricerche fatte da dispositivi mobili: le SERP dei motori di ricerca e di Google in particolare si stanno differenziando molto a seconda del contesto di utilizzo dell’utente e i motori di ricerca premieranno sempre di più i siti web ottimizzati per mobile quando la ricerca proviene da questa tipologia di dispositivo. Non realizzare un m-site entro un breve periodo potrebbe significare scomparire dalle prime pagine dei motori di ricerca quando sono utilizzati da dispositivi mobili, anche in presenza di un ottimo posizionamento sulle ricerche desktop, e le ricerche da dispositivi mobili sono in grande crescita, così come tutto il traffico generato dagli stessi.

In conclusione, questi sono strumenti diversi tra di loro che rispondono a esigenze diverse: non esiste una verità assoluta di utilizzo, ogni caso va analizzato a sé e bisogna valutare i pro e i contro degli strumenti applicati a ogni situazione. Conoscere le diverse possibilità di fornire il vostro contenuto agli utenti è certamente il punto di partenza giusto per fare le opportune considerazioni in merito ai vostri progetti.

Cerchiamo di sintetizzare le differenze in termini di vantaggi e costi delle due soluzioni:

Caratteristica | app | web app/m-site
Performance | Massime prestazioni di elaborazione lato hardware. | Minori per la presenza del browser come intermediario di elaborazione.

Integrazione

Massima integrazione con le funzionalità del dispositivo mobile e possibilità di interazione con altre applicazioni presenti nel dispositivo.

Minore integrazione hardware e maggiori limiti di interazione con tutta la sensoristica di bordo del dispositivo mobile.

Costo

Costo di sviluppo e di mantenimento maggiore e direttamente proporzionale ai sistemi operativi mobili per i quali viene offerta l’app.

Costi di produzione e di mantenimento molto bassi rispetto alle app.

Aggiornamento

Non immediato, l’utente che ha già scaricato e installato la nostra applicazione deve aggiornarla per ottenere le nuove funzionalità.
Il bug fixing deve avvenire prima della distribuzione e risulta più costoso.

Aggiornamento istantaneo: come le pagine di un sito web, l’utente non deve aggiornare nulla ma, collegandosi alle pagine web, troverà le nuove funzionalità tutte già aggiornate. Il bug fixing è immediato e può essere fatto anche dopo aver ricevuto i primi riscontri dagli utilizzatori.

Distribuzione | Attraverso gli app store. | Attraverso Internet.

Tabella 1.2 – Differenze app e web app/m-site.

1. James Tiberius Kirk, il Capitano di Star Trek - http://it.wikipedia.org/wiki/James_Tiberius_Kirk.

2. La prima telefonata Cooper la fece al suo collega Joel Engel dei Bell Labs di At&t, principale concorrente di Motorola all’epoca.

3. L’invenzione dello Short Message Service è contesa tra Neil Papworth, ingegnere inglese della Vodafone, e Riku Pihkonen, all’epoca stagista della Nokia. Il primo inviò un sms dal suo pc al cellulare di un collega (“MERRY CHRISTMAS” tutto in maiuscolo) il 3 dicembre 1992, perché non esisteva un modello di cellulare che potesse digitare dei caratteri; Riku Pihkonen invece fu il primo, all’inizio del 1993, a inviare un sms da cellulare a cellulare.

4. Il giorno della presentazione uffciale dell’iPhone da parte di Steve Jobs, lo smartphone andrà in vendita alle 18.00 del 29 giugno solo nel mercato statunitense.

5. TomTom è stato uno dei primi navigatori d’auto a larga diffusione sul mercato. TomTom Navigator è un dispositivo hardware e software, ma ha subito un forte contraccolpo in termini di vendite con l’avvento degli smartphone, che presentano ormai app di navigazione per automobili gratuite e non necessitano di alcun hardware aggiuntivo. TomTom è un marchio registrato http://www.tomtom.com/it_it/.

6. Dato aggiornato al dicembre 2013, fonte: Apple Inc.

7. Try & Buy: questo modello di approccio commerciale per la vendita del software esiste da decenni: chiunque si è spesso imbattuto in una versione light o freeware di un determinato software, limitata per lo più temporalmente più che in termini di funzionalità.

8. http://www.comscore.com/ita/ Società di Analytics.

9. Fonte dati Flurry Analytics, periodo di riferimento 2012.

10. Nei primi 5 mesi del 2012, l’88% delle sessioni delle app sono state generate da iPad, il 9% da Samsung Galaxy Tabe e il 3% dal Kindle di Amazon. Fonte dati: Flurry Analytics.

11. Fonte: AppAnnie: http://blog.appannie.com/app-annie-index-market-q2-2013/.

12. Tutti i dati dell’Android Market sono consultabili sul sito http://www.appbrain.com/stats/ e aggiornati quotidianamente.

13. Tutti i dati relativi al Windows Phone Marketplace sono consultabili sul sito http://www.windowsphoneapplist.com e aggiornati quotidianamente.

14. BRIC: acronimo che individua le quattro economie emergenti più forti al mondo: Brasile, Russia, India e Cina.

15. Fonte dati: http://www.nokia.com/global/about-nokia/investors/fnancials/reports/results---reports/.

16. Fu Mario Monti uno dei maggiori autori di questa iniziativa a favore della concorrenza e del consumatore.

17. Uno degli errori più divertenti e clamorosi delle mappe di Apple all’inizio fu rappresentato da un giardino pubblico enorme che aveva rimpiazzato completamente la stazione ferroviaria di Helsinki. La capitale fnlandese era rimasta isolata dal resto del Paese.

18. Saab, che costruisce anche motori aerei, oltre a quelli per autovetture, possiede uno dei brevetti più avanzati per la mappatura tridimensionale del territorio: alcuni velivoli Saab sono dotati di questo sistema, che ha una rilevazione topografca precisissima, con uno scarto di un solo centimetro.

19. Aggiungiamo che l’icona di Apple Maps è tremendamente simile a quella di Google Maps generando, a mio parere, anche molta confusione nei confronti dell’utente meno esperto.

CAPITOLO 2

TIPOLOGIE DI APPLICAZIONI

Un tentativo di classificazione delle app

Una celeberrima campagna pubblicitaria afferma che “esiste un’applicazione per ogni cosa”; possiamo dire che, se non è una verità a tutti gli effetti, non siamo però molto distanti dalla realtà.

I numeri che abbiamo esaminato dimostrano quanto siano ormai affollati i negozi di applicazioni: spesso esistono decine di app che fanno quasi tutte la stessa cosa, decine di calcolatrici, centinaia di liste di “cose da fare”, migliaia di app per le previsioni meteo; praticamente siamo in presenza di un mare magnum di applicazioni. Per questo motivo, prima di procedere anche solo nella decisione se sviluppare o meno un’applicazione, conviene fare un’analisi della concorrenza iniziale e capire se siamo in presenza di una nicchia sovraffollata, oppure possiamo riuscire ad avere successo. Per fare ciò, bisogna conoscere bene l’ambiente e i mercati in cui ci troviamo e dove vorremmo andare a competere con la nostra applicazione. Anche nel caso in cui avessimo un’idea unica e originalissima, bisogna comprendere in quale contesto vogliamo andare a svilupparla; nel caso siate così bravi da avere un’idea unica, molto presto questa vostra intuizione verrà copiata (è triste, ma è così) e, anche in questo caso, conoscere l’ambiente in cui si opera è di primaria importanza per il successo e la sopravvivenza.

Le applicazioni sono un fenomeno estremamente recente, ecco perché questo è solo un tentativo di classificazione: ci saranno molte evoluzioni in futuro e le cose potrebbero cambiare; per questo ho cercato di sviluppare una classificazione variabile a seconda di alcune caratteristiche di un’app.

Le categorie di utilizzo

Tutte le applicazioni presenti in uno store appartengono almeno a una categoria tassonomica. Le categorie sono chiaramente gestite dagli store stessi e variano leggermente da mercato a mercato, anche se, in generale, esistono sempre categorie come Produttività, Social Network, Sport e così via.

Chiaramente, gli store possono cambiare e modificare le categorie esistenti, così per esempio la categoria Meteorologia è stata aggiunta per poter contenere e isolare le migliaia di applicazioni sul meteo che sono state sviluppate nel corso del tempo. Con l’incremento del numero di app sviluppate, è possibile quindi creare nuove categorie più precise, e questo è l’esempio infatti dell’Apple Store, che ha aggiunto diverse voci all’elenco delle categorie.

Figura 2.1 – Elenco delle categorie dell’Apple App Store.

Focalizziamo l’attenzione sui due store principali: Google Play (Android) e Apple App Store (iOS); una prima differenza tassonomica di fondo delle due piattaforme è quella dei giochi. Apple li tratta come una delle varie categorie dell’App Store, mentre Google mantiene i giochi in una sezione separata rispetto alle altre applicazioni.

Ogni applicazione che viene pubblicata sugli store deve appartenere necessariamente a una categoria e la scelta della categoria di riferimento è estremamente importante per il marketing della vostra app. Per questo motivo è decisivo avere ben presente la tassonomia degli store, analizzando dove i vostri concorrenti o app simili alla vostra idea sono state posizionate.

Si noti come, per quasi tutte le categorie, non esistono categorie di secondo livello: tutto ciò genera un sovraffollamento di alcune sezioni, che contengono app anche molto diverse tra loro.

Agli sviluppatori, normalmente, è permesso selezionare una sola categoria per la propria applicazione; nella sezione giochi è quasi sempre possibile scegliere almeno due categorie dove inserire la propria app.

Figura 2.2 – Elenco delle categorie di Google Play.

Nella Tabella 2.1 presentiamo la tassonomia (gennaio 2013) di entrambi i negozi: un totale di 24 categorie per Apple e di 27 per Google Play. La maggior parte sono comuni a entrambi i negozi, mentre alcune sono più verticali in uno store, mentre rientrano in altre categorie nello store differente. Per esempio, Apple presenta la categoria Navigazione, che comprende tutti i navigatori satellitari e tutte le app che sfruttano a fondo il GPS, mentre Google non utilizza questa categoria e quelle app vengono inserite normalmente nelle categorie di Viaggi e info locali o in quella dei Trasporti. Oppure Google diversifica Fotografia e Video in due categorie distinte, mentre Apple le unifica in un’unica entità tassonomica. È facile comprendere come i due negozi e le categorie si assomiglino, ma è sempre bene comprendere in quale categoria è meglio inserire la propria applicazione; parleremo della scelta della categoria successivamente.

Una categoria invece che Apple non può e non vuole per il momento avere è quella dei Widget, che sono applicazioni un po’ particolari, funzionanti solo in ambiente Android e non programmabili per iOS, che tratteremo in un paragrafo ad hoc nel presente capitolo.

1. La categoria Edicola è nata per tutti coloro che vendono con periodicità i propri contenuti. Per questo non è una vera e propria categoria di appartenenza che lo sviluppatore può scegliere, ma un aggregatore di categorie diverse come News, Mode e tendenze, Viaggi ecc.

Tabella 2.1 – Categorie di primo e secondo livello presenti nell’Apple App Store e in Google Play a gennaio 2013.

I sistemi operativi

Una seconda classificazione possibile delle applicazioni è legata al sistema operativo in cui vengono sviluppate: quando una stessa applicazione viene realizzata per più sistemi operativi, viene definita app multi piattaforma o cross platform. Spesso, per risparmiare tempo e risorse umane in termini di sviluppo, esistono dei software che permettono di “trasportare”, completamente o parzialmente, un’applicazione sviluppata per un determinato sistema operativo in un altro sistema di sviluppo. Sostanzialmente, a ogni store corrisponde un sistema operativo.

Possiamo quindi creare la seguente classificazione:

Sistema Operativo | Azienda | App store
iOS | Apple | Apple App Store
Android | Google | Google Play
Windows Phone | Windows | Windows Phone Marketplace
Java Micro Edition (e vari) | RIM | Blackberry App World
Bada | Samsung | Samsung Apps
Vari | Facebook | Facebook Applicazioni

Tabella 2.2 – Classificazione delle applicazioni per sistema operativo e store.

Nei paragrafi successivi verranno approfondite le modalità di sviluppo delle applicazioni e le possibilità di transcodifica da una piattaforma a un’altra.

Applicazioni per smartphone e per tablet

Il mondo delle applicazioni, attualmente, si rivolge soprattutto a due tipologie di dispositivi: gli smartphone e i tablet e ultimamente anche a dispositivi che sono una via di mezzo tra i due denominati phablet, ovvero smartphone che hanno raggiunto quasi le dimensioni di un tablet.

Figura 2.3 – Smartphone, tablet e phablet a confronto.

Le differenze principali, tra loro correlate, che si devono tenere presente, sono le seguenti:

Dimensione dello schermo: gli smartphone hanno schermi piuttosto ridotti: lo standard del mercato si aggira intorno ai 3.5 pollici per iPhone (sono 4 per l’ultimo modello di casa Cupertino, l’iPhone 5) e tra i 3.5 e i 4 pollici anche per i cellulari Android. Ultimamente, le tendenze del mercato sembrano andare verso schermi un po’ più grandi, come per esempio il Samsung Galaxy Note II o l’iPhone 5, appunto. La dimensione dello schermo coinvolge anche l’interazione utente-dispositivo: gli smartphone possono essere impugnati con una mano sola e spesso si riesce a interagire con il device anche con una mano occupata. Alcune funzioni risultano più immediate, soprattutto in movimento, come l’utilizzo della fotocamera per scattare immagini o di un’applicazione per ascoltare musica.

Portabilità dello strumento: gli smartphone sono sempre con noi, nelle nostre tasche o nelle borsette: dimenticare a casa il proprio smartphone può essere un grande problema per molti, un vero e proprio incubo (che potrebbe trasformarsi in un sogno, di tanto in tanto). I tablet rappresentano spesso un sostituto del notebook, restano spesso a casa (da soli) ma sono compagni fedeli soprattutto negli orari serali. I tablet inoltre “vanno in vacanza”, affollano le spiagge, entrano nelle scuole e nelle università, salgono e scendono da treni e da aerei. Bisogna tenerne conto, occorre comprendere il contesto di utilizzo dello strumento e sfruttarlo in modo virtuoso. La differenza di portabilità tra gli strumenti può essere riassunta esaminando l’utilizzo del GPS, funzione presente in entrambi i modelli: negli smartphone, il GPS viene attivato spesso quando l’utente è realmente in mobilità, si sta veramente spostando (in auto, a piedi, coi mezzi pubblici, in bicicletta), mentre l’utilizzo del GPS sui tablet è molto spesso statico. L’utente sfrutta lo strumento ma mentre è fermo, in camera d’albergo, alla ricerca di un ristorante in zona, in casa mentre programma una passeggiata; quando pensate a come gli utenti utilizzeranno la vostra applicazione, comprenderne esattamente il contesto, a seconda del dispositivo utilizzato, potrà essere una delle chiavi del successo della vostra idea.

Funzionalità di chiamata: un’altra fondamentale differenza da non dimenticare è quella che gli smartphone sono telefoni, mentre i tablet, per il momento, non lo sono, tranne per le videochiamate attraverso le applicazioni di messaggistica istantanea, come Skype. Anche in questo caso, è fondamentale tener presente il contesto: l’utente smartphone sta interagendo con un telefono e la telefonata è ancora una delle funzionalità principali: sapere sfruttare la “vicinanza” app-telefonata o m-site-telefonata permette di ottenere riscontri reali e misurabili, nonché la possibilità di creare relazioni economiche sociali immediate (tratteremo in seguito nel libro gli aspetti So.Lo.Mo).

Quando pensate allo sviluppo delle vostre applicazioni, tenete sempre ben presenti questi aspetti e queste differenze fondamentali: difficilmente una persona si porterà dietro il proprio tablet per una giornata di sci o per una passeggiata (se lo mette nello zaino non è come averlo a portata di mano). La vostra applicazione che segnala le piste da sci e i sentieri, con tutte le informazioni correlate, dovrà essere sviluppata pensando soprattutto all’utilizzo su smartphone. Analizzando ulteriormente il contesto, dovremmo concentrare le nostre energie sulla massima usabilità delle nostre interfacce, possibilmente con una sola mano, mantenendo per esempio i pulsanti più distanziati del solito; questo perché spesso l’interfaccia verrà utilizzata con i guanti (guanti per touchscreen) e dovrà quindi essere velocissima per non interrompere l’attività fisica dell’utilizzatore, sfruttando al massimo il GPS anche in movimento e preservando il più possibile la batteria. Dovrà permettere delle chiamate a numeri utili (soccorso alpino, rifugi di zona ecc.) in modo veloce e semplice. Un’applicazione simile, pensata per un tablet, invece, dovrà avere delle caratteristiche differenti: una grafica più bella (ma anche più pesante, in termini di KB), che renda appagante la programmazione dei propri itinerari sciistici e montani; dovrà poi contenere molte più informazioni correlate: flora, fauna, storia e così via; potrà essere utilizzata con due mani e senza i guanti (al caldo sul divano dopo una bella giornata di sci), potrà permettere un’interazione più complessa e con altre applicazioni. Si potranno per esempio inserire le foto scattate durante la gita e “taggarle” nei punti del percorso fatto, fornendo una serie di statistiche avanzate, come il presunto consumo di calorie, i metri cubi di aria inspirata e tante altre amenità per gli amanti dei numeri come il sottoscritto.

La scelta tecnologica: app native, web app, widget

È molto importante avere ben chiare alcune differenze tecnologiche fondamentali: anche chi non sviluppa direttamente il codice dell’applicazione deve sapere quali sono le possibilità e le scelte tecniche che si possono fare in questi ambiti, anche perché cambiano le possibilità e i relativi costi.

Innanzitutto, una prima distinzione fondamentale è quella tra le app (native e non) e le web app.

Le applicazioni sono software sviluppati ad hoc in linguaggio macchina, che vengono scritte e compilate per i differenti sistemi operativi dei dispositivi mobili sui quali verranno installate; per esempio, le app per iOS (iPhone, iPod, iPad, iQualsiasicosa) sono scritte e compilate in linguaggio Object-C, quelle per il mondo Android in linguaggio Java, mentre quelle per Windows in .NET.

Le web app (i tab Home che possiamo aggiungere insieme ai tab delle app sui sistemi iOS, per esempio) sono delle pagine Html scritte di norma in Html5, Javascript e css, una sorta di “scorciatoia di navigazione” verso un contenuto ottimizzato per la visualizzazione da dispositivo mobile, ma trattasi sempre e comunque di navigazione del World Wide web.

Le applicazioni native invece implicano lo sviluppo di un codice non prettamente “web”. Vediamo di analizzare in modo schematico i vantaggi e gli svantaggi di entrambe le tipologie:

Utilizzo della sensoristica di bordo e interazione con altre app: questa è forse la distinzione più importante tra le due tipologie. Lo sviluppo delle app native permette l’interfacciamento con tutta la sensoristica del dispositivo a basso livello e, ove possibile, l’interazione con altre app presenti sul dispositivo (calendario, immagini utente, rubrica dei contatti ecc.); questa distinzione è quindi fondamentale nel caso in cui la vostra applicazione preveda l’utilizzo della tecnologia presente sui dispositivi mobili (come l’accelerometro, la bussola, la fotocamera, il GPS ecc.); in tutti questi casi è fortemente consigliato sviluppare un’applicazione nativa per interfacciarsi al meglio con il sistema operativo del dispositivo, così da ottenere le migliori prestazioni, riducendo al massimo il dispendio di batteria dello smartphone o del tablet. Ultimamente, grazie all’introduzione dell’Html5 e all’utilizzo di codice Javascript, si riesce a usare e a interagire con il GPS, fotocamera e audio anche con le web app, ma le prestazioni di calcolo e l’esperienza dal lato utente delle applicazioni sviluppate in modo nativo saranno sempre migliori. Nel caso in cui, invece, vogliate semplicemente erogare un contenuto dedicato e ottimizzato per una visualizzazione mobile, ma non avete bisogno di sfruttare la sensoristica di bordo, potrebbe essere molto più economico e rapido sviluppare il proprio contenuto in adaptive e responsive design, pensando agli utenti in mobilità e concentrandosi sull’usabilità e la fruizione di contenuto.

Costi e tempi: lo sviluppo di un’app nativa ha normalmente un costo molto maggiore rispetto a una web app. In primo luogo, per una semplice legge del mercato: per ogni sviluppatore nativo attualmente ci sono almeno venti sviluppatori web; la conoscenza dei linguaggi di programmazione delle app non è ancora così diffusa e i costi sono quindi superiori. Anche i tempi di sviluppo sono molto diversi, non solo per la scelta tecnologica ma anche perché, normalmente, le app native hanno delle funzionalità molto più complesse rispetto alle web app.

web vs Sistemi Operativi: una web app normalmente viene sviluppata in modo pressoché universale per tutti i dispositivi, con piccole differenze a livello di layout, a seconda della risoluzione e dimensione degli schermi. Normalmente, si tratta di scelte di adaptive e responsive design che utilizzano in modo corretto il codice in termini percentuali e i css. Inoltre, l’aggiornamento delle pagine web permette un aggiornamento istantaneo anche della web app. Le applicazioni native necessitano invece dell’installazione del software sul sistema operativo: lo sviluppo quindi è dedicato per tipologia di SO e l’adattamento è singolo. Inoltre, l’aggiornamento dell’applicazione nativa necessita di una reinstallazione dell’app da parte dell’utente e non semplicemente di un nuovo utilizzo dell’app.

Distribuzione: le web app hanno tempi e costi di distribuzione pressoché nulli. Una volta che sono state “uploadate” le pagine Html che compongono la nostra web app su un server web accessibile, la medesima è immediatamente disponibile dal lato utente e accessibile via browser da tutti i dispositivi. Le app native invece devono essere scaricate da un app store da parte degli utenti. Una volta scritta e compilata la nostra app nativa per un determinato sistema operativo, bisogna fare la cosiddetta “sottomissione dell’app nello store”, ovvero fare un upload del pacchetto compilato attraverso le piattaforme fornite agli sviluppatori. Il processo di sottomissione e di pubblicazione dell’app nel negozio di distribuzione non è immediato; per esempio i tempi attuali in ambiente iOS sono di circa sette giorni e mai di meno, per iOS inoltre lo sviluppatore deve avere un account come developer presso Apple e pagare una relativa piccola quota annuale. I tempi e i costi di distribuzione delle app native sono quindi molto maggiori rispetto alle web app. Da sottolineare, però, che la presenza di un proprio prodotto/servizio/contenuto digitale all’interno di uno o più store permette una maggiore esposizione dei vostri prodotti/servizi/contenuti digitali: la presenza in uno store è un ampliamento della propria comunicazione digitale verso un mercato e un ambiente che prima non esistevano. Non deve essere vissuto come uno step aggiuntivo e meno immediato rispetto alla web app, bensì come un affacciarsi verso un nuovo ambiente digitale: gli utenti, ormai, non cercano più solo sul web, ma anche all’interno degli app store. Se pensate infne di vendere la vostra applicazione, è vero che è possibile farlo con entrambe le soluzioni e che attraverso le web app non si paga la commissione allo store (intorno al 25-30%, a seconda della nazione dello sviluppatore), ma è anche vero che gli utenti che accedono agli store sono molto più propensi all’acquisto di un’app rispetto a coloro i quali stanno navigando semplicemente via browser. La spontaneità, l’immediatezza e l’emotività d’acquisto in un app store sono e saranno sempre superiori rispetto al World Wide web. Solo il fatto, per esempio, che l’utente Apple non deve reimmettere ogni volta il numero di carta di credito per comprare, ma semplicemente inserire la propria password, è un elemento che cambia moltissimo i tassi di conversione monetari e le dinamiche di acquisto di questa tipologia di software, che costano spesso quanto un caffè o poco più. Ci sono alcuni accorgimenti, che defnirei dei veri e propri “work around”, delle linee guida degli store, che permettono di pubblicare nello store anche una sorta di web app, facendola sembrare, a livello di codice, un’app nativa; sono però sempre soluzioni molto “borderline” e il gestore dello store potrebbe, aggiornando le linee guida, arrivare a eliminare la vostra app in un secondo momento.

Online e Offine: le web app, come il nome stesso suggerisce, sono necessariamente collegate al web e funzionano, quindi, solo in presenza della connessione Internet. Attraverso una buona gestione della cache è possibile far funzionare almeno parzialmente le web app anche in assenza di connettività, ma solo nel caso in cui il contenuto sia stato già visualizzato in precedenza (identico alla navigazione offine di contenuti già visualizzati). Un’applicazione nativa funziona sempre anche in assenza di Internet. È chiaro che spesso le app native forniscono dei servizi che necessitano della connessione, in quanto devono essere aggiornati e quindi anche una app nativa può risultare pressoché inutilizzabile come una web app. Pensiamo per esempio a un’applicazione di previsioni del tempo; che sia app nativa o web app, avrà sempre e comunque bisogno di una connessione Internet per potermi inviare le previsioni del tempo aggiornate, quindi il cuore dell’applicazione necessita sempre di una connessione e da questo punto di vista non cambia molto se sia stata sviluppata come app nativa o web app. Lo stesso discorso vale, per esempio, per un’applicazione per la consultazione delle quotazioni di borsa. È chiaro che anche in questo caso ho bisogno di una connessione per vedere le quotazioni aggiornate e quindi non c’è molta differenza tra le due tipologie tecniche; tuttavia, in questo esempio, un’applicazione nativa potrebbe permettere la consultazione del proprio portafoglio azionario, mentre con una web app anche un’operazione del genere è impossibile in assenza di connettività.

Meritano invece un discorso a parte i cosiddetti widget di Android. Secondo la stessa Google[20]: “I widget sono delle mini applicazioni che funzionano sulla home del vostro telefono”. I widget sono quindi sempre presenti e normalmente funzionanti in una sorta di “modalità ascolto”, pronti ad attivarsi e a interagire con l’utente senza che questi lanci l’applicazione stessa. Esempi comuni di widget sono le varie tipologie di orologi, calendari, launcher alternativi ecc. Il vantaggio dei widget rispetto alle applicazioni native è di essere virtualmente sempre attivi e funzionanti e sempre aperti/lanciati.

Uno dei widget che ultimamente ha riscosso maggiore successo è quello di Facebook, il widget cosiddetto “Facebook Home”, che è stato pubblicato su Google Play il 12 aprile del 2013. Sostanzialmente, questo widget trasforma completamente la home dello smartphone tenendolo costantemente connesso al social network. L’obiettivo dichiarato di Facebook è di costruire un’esperienza mobile intorno alle persone e non intorno alle app, il tutto attraverso un widget contenente tante mini app attivabili o meno dal lato utente. Ogni individuo può decidere, per esempio, se visualizzare immediatamente sul proprio schermo le immagini pubblicate dai propri amici in tempo reale e interagire subito con la foto e l’amico: un rapporto sempre più diretto e immediato verso il social network. Chiaramente, l’interesse di Facebook è di rendere molto attivo e connesso il proprio utente facendolo interagire sempre di più in termini digitali. Più interazione crea più contenuto, che crea più audience, più reach ed esposizione in termini di advertising. Attualmente, il concetto di widget non esiste su iOS e non esisterà nel breve periodo perché Apple si è sempre mostrata scettica anche in passato nel permettere un’interazione così continuativa e costante con il proprio sistema operativo. In questo momento, la cosa che si avvicina maggiormente al concetto di widget è il listato delle notifiche, ma la mancanza di interazione immediata rende completamente diverso il concetto sui due sistemi operativi.

20. http://google.about.com/od/a/g/widget.htm di Marziah Karch (Google Guide).

CAPITOLO 3

APPLICAZIONI E WORLD WIDE WEB

Differenze e sinergie della comunicazione del web e delle app

Fino a questo momento abbiamo parlato di smartphone e tablet in relazione alle applicazioni, ma teniamo presente che questi device contengono anche i browser per la navigazione in rete. Smartphone e tablet hanno liberato Internet e stanno rivoluzionando nuovamente la comunicazione digitale; fino al 2008, quando si pensava a realizzare un sito web, l’immagine del nostro potenziale interlocutore era quella di una persona seduta davanti a una scrivania o a un tavolo, comunque statica, intenta a navigare con il suo computer dallo schermo più o meno grande. Le situazioni di maggiore dinamicità erano l’utilizzo del pc nei trasporti pubblici (treni, aerei) e durante le attese degli stessi (stazioni ferroviarie, aeroporti), ma in questi casi quasi sempre per lavoro o per soste e spostamenti prolungati, spesso scomodi e senza alcun tipo di privacy. Il nostro interlocutore era quindi statico o in una “mobilità statica”. I dispositivi mobili, in particolar modo gli smartphone, hanno invece stravolto questo concetto: quando navigo su un sito Internet con il mio telefonino, mi trovo nelle situazioni più disparate; anzi, molto probabilmente non sono seduto a un tavolo o a una scrivania, altrimenti utilizzerei la mia postazione desktop. Molto spesso mi sto spostando, sto camminando, sono all’aria aperta, per le vie di una città, accalcato in piedi in metropolitana o in coda a uno sportello. Per questi motivi la comunicazione deve assolutamente adattarsi al contesto in cui si trova il nostro interlocutore.

Mentre nel 2007 e nel 2008 il numero di visite ai siti Internet provenienti da dispositivi mobili era un dato estremamente limitato e spesso trascurato dai responsabili della comunicazione e del marketing dei siti web, oggi non è più accettabile trascurare questo fenomeno, in quanto le navigazioni su siti Internet non ottimizzati e non costruiti per la navigazione mobile hanno raggiunto livelli ormai significativi e, in molti casi, permetterebbero quel contatto verbale e fisico e, soprattutto, quei tassi di conversione che non si riscontrano in nessun caso online.

I tassi di crescita della navigazione da dispositivi mobili in Italia sono impressionanti, un fenomeno pressoché inarrestabile. Ho seguito personalmente questa ricerca e questo fenomeno dal 2008 e svolgo ogni anno un report con i dati ShinyStat su questo e altri eventi.

Figura 3.1 – Quota percentuale di visite provenienti dall’Italia, effettuata da dispositivi mobili rispetto a dispositivi fissi dal 2010 al 2013. Fonte: ShinyStat. Campione: 1,35 miliardi di visite.

In oltre quindici anni di lavoro in ambito digitale, raramente ho visto dei tassi di crescita così elevati e che continuano nel corso del tempo. Anche analizzando semplicemente l’ultimo triennio, è sbalorditiva la crescita delle visite da dispositivi mobili: a gennaio del 2010 le visite da mobile erano solo il 2,4% rispetto a quelle da desktop, dopo un anno erano già passate al 5,8%, con una crescita di 2,4 volte; in ambito digitale siamo abituati a fenomeni con tassi di crescita del genere nel momento iniziale di espansione. Nel gennaio del 2012 le visite da dispositivi mobili arrivavano già in doppia cifra rispetto ai fissi al 12,1%: oltre 1 visita su 10 dall’Italia proviene quindi da dispositivi mobili; anche in questo caso con una crescita più che doppia in soli dodici mesi, la quota cresce di 2,1 volte. A gennaio del 2013 la quota continua a incrementare, accelerando e arrivando al 24,1%: praticamente 1 visita su 4 proviene da dispositivi mobili, un dato incredibile se paragonato a quello di soli tre anni prima, aumentato praticamente di 10 volte. Questi tassi di crescita sono sbalorditivi anche nel digitale. A novembre del 2013, ultimo dato disponibile attualmente, le visite da dispositivi mobili sono diventate pari al 37,3% rispetto a quelle da dispositivi fissi: oltre una visita su tre proviene da mobile. Questo significa che un sito non ottimizzato per mobile riesce a “sprecare” molto probabilmente circa un terzo del suo traffico; stiamo parlando di visite provenienti dall’Italia, ma basta vedere ancora quanti siti web in Italia utilizzano la tecnologia Adobe Flash[21], anche solo per testare il sito o per fare un carosello: questi siti web stanno letteralmente gettando al vento quasi la metà dei loro interlocutori, e non, potenziali, perché stiamo parlando di visite a siti web, quindi di persone che sono già all’interno di un sito Internet. Un dato “di costume” che si può notare nel grafico dell’andamento sono i leggeri picchi che si possono riscontrare in ogni anno: quei punti di massimo relativo corrispondono sempre al mese di agosto, dove l’utilizzo del mobile invade tutte le spiagge e le montagne italiane.

Secondo una mia personale previsione, nel corso dell’estate 2014, le visite da dispositivi mobili in Italia supereranno quelle da desktop. Siamo arrivati al punto di non ritorno: il mobile è letteralmente esploso in Italia, grazie anche all’amore pluriennale che abbiamo sempre avuto nei confronti dei telefonini; il Bel Paese è una delle 60 nazioni in cui la penetrazione mobile ha superato il 100%, ovvero ci sono più utenze mobili attive che abitanti.

Vediamo ora di isolare il solo andamento, in termini assoluti, delle visite da dispositivi mobili, distinguendole per sistemi operativi.

Osserviamo come iOS rimane ancora, forse per poco, il sistema operativo mobile che genera maggiori visite ai siti web in Italia, nonostante da oltre un anno le vendite dei dispositivi Android abbiano superato abbondantemente quelle dei melafonini e melatablet; ma in tutta questa ricerca parliamo di dati di utilizzo di dispositivi mobili e non di vendita dell’hardware in sé: è l’utilizzo che interessa e gli utenti Apple, per il momento, sono ancora i veri power user della navigazione Internet da dispositivi mobili; una quota dei possessori di smartphone Android naviga molto poco, usando il telefono come prima usava un modello Nokia, ma con un bel po’ di social network e gaming in più. Il grafico della Figura 3.2 evidenzia in modo chiaro come per il momento la battaglia sia limitata a due player, gli altri sono ampiamente distaccati anche se Windows mostra qualche segnale di vita, soprattutto in seguito all’acquisizione di Nokia e all’uscita del Lumia. Non consideriamo i giochi come conclusi, anzi, perché stiamo parlando di un mercato nuovo, di pochissimi anni (basta guardare la curva di Android), in rapidissima evoluzione.

Ecco nella Figura 3.3 com’era la fotografia del mercato a gennaio del 2010.

Figura 3.2 – Visite provenienti dall’Italia su siti web, effettuate da dispositivi mobili, distinte per sistema operativo mobile dal 2010 al 2013. Fonte: ShinyStat. Campione: 1,35 miliardi di visite.

Figura 3.3 – Quote di mercato (gennaio 2010) di utilizzo, in termini di visite provenienti dall’Italia su siti web, effettuate da dispositivi mobili. Fonte: ShinyStat.

Il sistema operativo di Apple dominava il mercato con oltre il 60% delle visite: nel 2010 iPhone e iPad erano certamente i dispositivi migliori al mondo per navigare in rete e il consenso dei consumatori era unanime. Da notare come il secondo player fosse Nokia con Symbian, all’epoca ancora vivi e indipendenti; medaglia di bronzo per il Blackberry che, nonostante un browser non esattamente user friendly, riusciva comunque a ottenere un’ottima quota di utilizzo. Staccati, e di molto, Android e Windows.

Ora rivediamo la stessa fotografia, ma scattata solo tre anni dopo, nel novembre del 2013.

Figura 3.4 – Quote di mercato (novembre 2013) di utilizzo, in termini di visite provenienti dall’Italia su siti web, effettuate da dispositivi mobili. Fonte: ShinyStat.

La situazione in poco meno di quattro anni è cambiata radicalmente; ricordiamo anche che le visite da dispositivi mobili sono più che decuplicate: in primo luogo, sono scomparsi completamente il secondo e il terzo player, rispettivamente Nokia e RIM, che finiscono sotto il punto percentuale con un declino rapidissimo e, sembra, senza via di uscita. Questi due soggetti sono stati letteralmente divorati dal sistema operativo di Google; Android ha ormai raggiunto Apple e molto probabilmente la supererà presto; infine abbiamo Windows che, con tutte queste rivoluzioni tecnologiche, riesce a mantenere una piccola quota di mercato, recuperando dal 2012, dove era scesa all’1,5%. Non darei quindi Windows per spacciata nella guerra mobile, mentre Nokia ormai non esiste più e anche Blackberry, mia opinione personale, non avrà ancora molta vita, a meno di qualche acquisizione da da parte di un player digitale importante, come potrebbero essere Facebook o Yahoo!.

Infine, come ultima analisi della ricerca che ho condotto su dati ShinyStat, vediamo la distinzione, all’interno del mondo Apple, tra utilizzo di smartphone e tablet; per scelta personale le visite eseguite da iPad Mini rientrano all’interno della quota dell’iPad (Figura 3.5).

Anche questo grafico è molto interessante: vediamo come il traffico da iPad, pur partendo con un certo ritardo, per il fatto che i tablet Apple sono arrivati molto dopo l’arrivo dell’iPhone, ha superato per un certo periodo di tempo le visite da iPhone. Dobbiamo sempre tenere presente il contesto: lo smartphone viene acceso molto più spesso e a intermittenza: si accende il browser, si fa una navigazione molto rapida e veloce e poi lo si rimette di nuovo in tasca.

Figura 3.5 – Andamento delle visite provenienti dall’Italia su siti web, effettuate da dispositivi mobili Apple. Fonte: ShinyStat.

L’iPad ha letteralmente cannibalizzato l’utilizzo del desktop e del notebook nelle ore serali: lo si accende subito, è leggero, si passa velocemente tra le persone e senza fare grandi danni. Quindi la navigazione da tablet risulta molto più lunga e continuativa e produce un numero di visite molto elevato per singola sessione di utilizzo. Il fenomeno dell’esplosione delle visite mobile comunque è molto chiaro, poiché vi è una diretta proporzionalità delle due curve e andamenti molto simili. L’iPhone ha ora nuovamente superato l’iPad grazie all’uscita del modello 5 e anche al nuovo iOS7: lo schermo di mezzo pollice più grande, le nuove interfacce e le gestioni dei tab di Safari nella versione 7 del sistema operativo hanno reso la navigazione web molto più gradevole anche da smartphone, aumentando in modo sensibile le visite anche per una singola sessione di utilizzo; se a ciò aggiungiamo che sono anche aumentati i siti web ottimizzati per smartphone, rendendo meno penosa l’esperienza degli utenti, il quadro è chiaro. L’impennata di visite a novembre 2013 è dovuta soprattutto ai primi due fattori.

Abbiamo quindi osservato come le visite ai siti web si sono molto evolute nel corso del tempo; è necessario quindi sfruttare l’ambiente digitale a 360 gradi: la comunicazione deve partire dal sito Internet, continuare sui social network, focalizzandosi più sulle conversazioni che sulle conversioni, e deve approdare nel mondo mobile ponendo l’attenzione sulle funzioni e sugli utilizzi e comprendendo le esigenze del proprio interlocutore quando è in mobilità.

Le visite ai nostri siti web provenienti dai tablet e dagli smartphone sono estremamente sinergiche rispetto a quelle generate dai computer desktop. Un primo livello di sinergia è rappresentato dalla distribuzione del traffico nel corso della settimana. Il grafico della Figura 3.6 rappresenta la media delle visite a 30.000 siti web italiani, distribuiti in 48 categorie tassonomiche provenienti da dispositivi fissi e mobili nel corso della settimana nel 2013.

Figura 3.6 – Andamento settimanale delle visite da desktop e mobile su 30.000 siti web. Fonte: ShinyStat.

La maggior parte dei siti Internet, tranne rare e ovvie eccezioni, riscontra una significativa diminuzione di visite proprio durante il weekend: questo andamento del traffico web è caratteristico della nascita del World Wide web, inizialmente anche molto più accentuato per la mancanza di connettività domestica: molte persone potevano accedere a Internet solo dal posto di lavoro o da scuola (tipicamente le università) e molto meno da casa; essendo il sabato e la domenica giorni tipicamente festivi, gli utenti lontani dalle loro postazioni di lavoro non avevano accesso alla rete e il traffico web ne risentiva pesantemente. La navigazione da dispositivi mobili e l’utilizzo delle applicazioni, invece, restano più costanti durante tutto l’arco della settimana: li abbiamo sempre per le mani e sono sempre con noi e sostanzialmente sempre connessi; in questo modo le visite da dispositivi mobili riescono a compensare, almeno parzialmente, la perdita di traffico tipica dei fine settimana.

Una seconda sinergia che bisogna saper sfruttare, sempre a livello temporale, è relativa alle fasce orarie di navigazione degli utenti. Anche qui il traffico web ha sempre seguito l’andamento della giornata lavorativa, con la maggior parte delle visite concentrate durante l’orario di lavoro e la pausa pranzo o la fine della giornata lavorativa. L’avvento degli smartphone e soprattutto dei tablet ha cambiato tutto.

Il grafico della Figura 3.7 rappresenta le visite a 30.000 siti web italiani durante le 24 ore della giornata nel corso del 2013.

Figura 3.7 – Andamento orario delle visite da desktop e mobile su 30.000 siti web. Fonte: ShinyStat.

I siti Internet, in media, vengono visualizzati dai dispositivi fissi con dei picchi di traffico diurni, in particolar modo in tarda mattinata, pausa pranzo e durante l’arco del pomeriggio. Con la chiusura degli uffici, le navigazioni da desktop ai siti web diminuiscono drasticamente. Tutto questo non avviene, invece, dai dispositivi mobili. Questi ultimi vengono accesi molto prima alla mattina: tantissimi utenti si svegliano e iniziano subito a navigare in rete o a utilizzare applicazioni ancora coricati nel letto alle prime ore dell’alba. Anche in questo caso c’è un picco durante la pausa pranzo, dove l’utente ha un po’ di tempo libero e dove spesso il suo compagno di tavola è un telefonino o un tablet (sempre meglio che mangiare da soli); in generale, la navigazione dai dispositivi mobili rimane più costante durante tutto l’arco della giornata con un altro picco anche nell’orario di uscita dal lavoro. Le persone escono dagli uffici e salgono sui mezzi di trasporto pubblici dove i nuovi strumenti tecnologici hanno sostituito quasi del tutto romanzi, riviste e letture da metropolitana; ma la differenza sostanziale si nota alla sera, quando la navigazione mobile subisce un’accelerazione inversamente proporzionale a quella da dispositivi fissi. I tablet, in modo particolare, hanno cannibalizzato moltissimo il traffico da personal computer: ormai non accendiamo più il portatile sul divano ma controlliamo le mail, i social e navighiamo un po’ dal nostro tablet o dal nostro smartphone, chiaramente sempre sul divano. L’effetto del doppio schermo esiste fortemente anche in Italia: guardo la televisione e navigo/twitto/aggiorno Facebook contemporaneamente; questo fenomeno è dilagato grazie alla portabilità degli strumenti mobili, ineguagliabile da parte dei notebook.

Tale effetto è stato talmente evidente che gli stessi produttori di notebook si stanno spostando velocemente verso soluzioni ibride notebook-tablet estremamente interessanti, un mercato dove Microsoft (soprattutto grazie al modello Surface) riesce ancora a esprimersi molto bene; un settore quindi ancora molto inesplorato, ma estremamente interessante.

Figura 3.8 – Il Surface di Microsoft: un notebook estremamente potente che si trasforma in tablet.

Brevi cenni sugli m-site

Non bisogna assolutamente dimenticare, quindi, che i dispositivi mobili vengono utilizzati sempre di più dagli utenti anche per navigare nel vostro sito Internet, utilizzando il browser “di bordo” oppure uno di terze parti installato tramite il download di un’applicazione.

Le persone ormai sono sempre più connesse costantemente alla rete. In modo particolare, gli italiani sono sempre stati molto più attratti dai cellulari rispetto ai personal computer; per questo gli smartphone stanno “portando in Internet” molte nuove fasce di utenti che prima non avevano mai navigato oppure che lo facevano saltuariamente o solo dal posto di lavoro e di studio, non avendo una connessione domestica. Le offerte degli operatori telefonici che offrono lo smartphone acquistabile in modo rateizzato, comprensivo del traffico dati dell’operatore stesso, hanno reso ancora più appetibile la navigazione in mobilità e tramite dispositivi mobili; se a ciò aggiungiamo che le nuove famiglie italiane (diciamo coloro che hanno tra i trenta e i quarant’anni) spesso non dispongono di una rete telefonica fissa, ma solo di utenze mobile, l’acquisto della connettività tramite 3G è molto più conveniente rispetto a un’utenza ADSL domestica. Il prezzo medio di una connessione ADSL casalinga senza canone per il telefono fisso si aggira intorno ai 20/30 euro al mese, mentre la connettività 3G di un tablet ha un costo medio di 5/10 euro al mese[22]. Per questo motivo, chiunque oggi abbia un sito Internet deve considerare in modo molto attento questo fenomeno che è obiettivamente in fortissima espansione.

Nel caso in cui il vostro sito Internet non sia stato ottimizzato per un dispositivo mobile, le cose da controllare immediatamente sono sostanzialmente tre:

1.Verifcate come è visualizzato il vostro sito Internet da uno smartphone (possibilmente, almeno da un telefono Android, uno iOS e uno con sistema operativo Windows); personalmente, consiglio un iPhone, un Samsung Galaxy e un Nokia Lumia. Fatelo connettendovi sia con il wi-fi sia in 3G. Analizzate la semplicità di navigazione dei contenuti e le varie funzionalità del vostro sito Internet. Riuscite ad accedere facilmente ai pulsanti dei menu? Il testo è leggibile? Le pagine si caricano velocemente e correttamente? Si riesce in modo semplice a raggiungere una conversione (per esempio, a fare un acquisto sul vostro e-commerce o a inviare una richiesta di informazioni al vostro hotel?) Utilizzate del codice non visualizzabile come il linguaggio Adobe Flash®? Contate quante volte avete bisogno di ingrandire lo schermo con lo zoom e utilizzare la funzione inversa. L’esperienza lato utente risulta gradevole e funzionale? Rispondete con onestà e in modo oggettivo.

2.Fate la stessa cosa, ma utilizzando un tablet; anche in questo caso, possibilmente, ricorrendo ai tre sistemi operativi principali. Per i tablet spesso le azioni precedenti risultano meno diffcili e complesse, grazie a uno schermo molto più grande e a una usabilità simile a quella dei notebook.

3.Controllate infne all’interno del software di Analytics implementato sul vostro sito Internet quante visite attualmente il vostro sito web non ottimizzato riceve dai dispositivi mobili. Dovreste ottenere un grafco simile a quello rappresentato nella Figura 3.9.

Molto probabilmente, anche il vostro sito Internet avrà una percentuale come quella mostrata, nel caso operiate in settori ad alta mobilità come il turismo, la finanza, i trasporti; questa percentuale potrebbe essere anche molto maggiore, in altri settori a minore mobilità, ma sempre e comunque una quota importante rispetto alle visite totali al vostro sito Internet. Quasi certamente, anche il vostro sito web non può ignorare coloro che vi accedono dai dispositivi mobili. Voi stessi dovete testare il sito e possibilmente vedere anche come gli altri eseguono le prime due fasi del processo di verifica di usabilità; personalmente, vi consiglio di prestare il vostro dispositivo a vostra mamma o a vostra nonna (dipende dall’età che avete) e guardare come navigano, o cercano di navigare, il vostro website: vostra nonna è il vostro miglior beta tester.

Figura 3.9 – Report della distribuzione delle visite a un sito Internet per sistema operativo fisso o mobile.

Molto probabilmente, soprattutto nella fase 1, eseguire navigazioni che risultano semplici e veloci dai desktop richiede molto più tempo e soprattutto molta più pazienza quando vengono fatte da un dispositivo mobile; in alcuni casi la pazienza deve essere qualcosa di semi-mistico, perché navigare molti siti web non ottimizzati con uno smartphone, magari dovendo compilare anche dei form, sono un’operazione e un’esperienza spesso molto faticose e frustranti.

Dopo aver analizzato l’esperienza lato utente, spesso tragica, di navigazione sul vostro sito Internet, e avere misurato esattamente di quanti utenti state testando la pazienza in modo molto serio, una quarta cosa che dovete fare è rispondere alla seguente domanda:

4.La mia attività ha uno o più punti vendita aperti al pubblico?

Nel caso in cui rispondiate affermativamente a questa domanda, il mio consiglio è quello di chiamare immediatamente la vostra web agency, chiedendo un incontro per pianificare un’ottimizzazione del vostro sito Internet in ottica mobile; poiché avete urgenza, potete semplicemente chiedere: “Vi voglio incontrare per fare l’m-site del mio sito!” Nel caso in cui la web agency non capisca di che cosa stiate parlando, un altro mio consiglio è di cambiarla immediatamente.

Questo perché non è accettabile, perlomeno da professionisti del settore, non essere aggiornati: state perdendo occasioni e quote di mercato, non curate la vostra nicchia e gli aspetti locali; non dimenticate che gli smartphone hanno il GPS e che il GPS stesso porta i clienti all’interno del vostro negozio, attraverso il vostro sito web, e questo succede per chiunque abbia un’attività aperta al pubblico: bar, hotel, ristoranti, farmacie, officine, gommisti, negozi, tabaccherie, fioristi, autosoccorso.

Penso che ognuno di voi abbia già avuto almeno un’esperienza di ricerca in mobilità “georeferenziata”. Porterò un esempio reale che mi è capitato personalmente e che può essere adattato alla vostra attività, un caso studio emblematico per coloro che trascurano questi aspetti.

Cercando con uno smartphone su Google “camicie su misura Milano”, e attivando il GPS in modo che fornisca dati geolocalizzati vicini a dove mi trovo, ottengo i risultati che ripropongo nella Figura 3.10: come prima posizione c’è il sito Itailor, che ha un ottimo posizionamento essendo il primo risultato con una ricerca abbastanza concorrenziale[23].

Figura 3.10 – Ricerca eseguita su Google.it da dispositivo mobile con GPS attivo con chiave di ricerca localizzata “camicie su misura Milano”.

Molto probabilmente, il sito Itailor ha anche investito dei soldi in SEO per ottenere quella posizione e il relativo traffico organico (quindi senza pagare nulla per ogni clic) da Google. Peccato poi che cliccando sul risultato e accedendo a questo sito succede quello che rappresentiamo nella Figura 3.11.

Figura 3.11 – Visualizzazione della homepage del sito Itailor, primo nei risultati organici su Google.

Una “bella” schermata nera, poiché il sito non solo non è stato ottimizzato per i dispositivi mobili, ma è stato realizzato in linguaggio Flash®, uno standard di programmazione che non viene letto da tutto il mondo mobile. A questo punto, torno indietro sul listato di Google e clicco sul risultato successivo: ottengo il sito di Boggi®, perfettamente ottimizzato per i dispositivi mobili, come si può vedere dalla Figura 3.12, che mi permette di trovare immediatamente e in modo estremamente semplice gli indirizzi, gli orari, i numeri di telefono e i link al sistema di mappe, in modo che io possa subito chiamare o ricevere indicazioni su come raggiungere a piedi il negozio più vicino alla mia posizione: questo vuol dire fornire un servizio al cliente!

Mi reco da Boggi e acquisto veramente una camicia; l’altro negozio ha perso un potenziale cliente, semplicemente per avere dimenticato persone come me. Se pensano che io sia un’eccezione e un fanatico di tecnologia si devono ricredere, perché sono ormai moltissime le persone come il sottoscritto. Consideriamo alcuni dati riportati direttamente anche dai motori di ricerca:

Il 40% di tutte le ricerche mondiali di Google che contengono un’indicazione geografca sono state fatte da dispositivi mobili. Stiamo parlando di milioni di ricerche al giorno; è un dato enorme, che sottolinea anche una certa urgenza e un bisogno immediato di ciò che si sta cercando. Una ricerca “ristorante Roma” fatta da desktop indica un bisogno certamente inferiore rispetto alla stessa fatta da uno smartphone. Fonte: Google Mobile Search Moments Study.

Figura 3.12 – Le pagine ottimizzate per smartphone del sito di Boggi®.

Lo stesso dato diventa del 50% per quanto concerne le ricerche su Bing e Yahoo!. Fonte: Bing al CTA Wireless.

Il 59% delle visite ai siti web in seguito a una ricerca local su Google, eseguite da dispositivo mobile, si trasformano poi in visite fsiche al punto vendita o nel luogo di attività fsico. Un tasso di conversione del 59% è sempre stato un miraggio per il mondo digitale: nel nostro settore siamo abituati a tassi di conversione molto bassi, compresi spesso tra lo zero e il 5%; tassi di conversione come quello presentato da Google nella sua ricerca sono straordinari e molto simili a quelli del commercio offine. Questo a dimostrazione che gli smartphone sono il collegamento tra commercio online e commercio offine e sono il punto d’incontro tra il mondo digitale e quello analogico (reale); essi sono l’anello che mancava per la vera e completa rivoluzione della rete. Fonte: Google Mobile Search Moments Study.

Trasformare i siti web in m-site o applicazioni

Se nel paragrafo precedente sono riuscito a convincervi a ottimizzare il vostro sito web per i dispositivi mobili, ora cercherò di fornirvi alcune indicazioni generali su come farlo.

La problematica principale che si incontra nella trasposizione di un sito web in versione ottimizzata per mobile è quella dell’enorme differenza nella dimensione dello schermo che esiste tra una postazione fissa e un dispositivo mobile e nella precisione dei clic lato utente. Se a ciò aggiungiamo che in un caso viene usato un puntatore molto piccolo e preciso (il nostro fidato mouse o trackpad), nell’altro caso invece abbiamo a che fare con le nostre dita spesso imprecise, a volte esageratamente grandi[24].

Lo spazio diventa quindi preziosissimo e le vostre 25 voci di menu presenti nel sito standard dovranno essere necessariamente ridotte o perlomeno distribuite e rese accessibili in modo diverso rispetto al sito desktop.

Sintetizzando: abbiamo meno spazio a disposizione, dobbiamo essere molto chiari nella visualizzazione dei contenuti, cercando di mantenere un impatto grafico leggero (non dimentichiamo chi si connette in mobilità dove la banda Internet non è sempre il massimo).

È fondamentale quindi comprendere quali contenuti presentare agli utenti che si connettono con gli smartphone e con quale ordine prioritario; come ho spiegato precedentemente, non è solo una questione tecnica e di codice, non è solo attraverso il responsive design che possiamo rispondere alle esigenze e ai bisogni del nostro utente in mobilità: dobbiamo andare oltre e pensare sempre al contesto, dobbiamo passare dal responsive design all’adaptive design. Nuovamente, dobbiamo pensare ai nostri interlocutori e chiederci: “Per quale motivo una persona dovrebbe visualizzare il mio sito Internet con uno smartphone? Che esigenze e bisogni ha in quel momento?”. Cercare di rispondere a questa domanda è fondamentale per poter stendere un ordine gerarchico dei propri contenuti.

Continuiamo l’esempio dei negozi di camicie riportato nel paragrafo precedente: il sito ottimizzato per i dispositivi mobili non deve essere una mera trasformazione del mio sito standard, più leggibile, con una font più grande e un menu più facilmente navigabile. Bisogna partire sempre domandandosi perché una persona dovrebbe interagire con il mio sito in questo modo… nel caso delle camicie, forse perché ha un problema con una camicia che deve risolvere immediatamente. Si sta probabilmente muovendo e comunque non è nei suoi luoghi abituali (altrimenti saprebbe dov’è il suo negozio di camicie). Quindi, mentre sul mio sito standard cerco di rendere la navigazione una vera “esperienza catalogo patinato”, con immagini grandi e accattivanti e poco testo, puntando molto sulla collezione, nel caso del sito ottimizzato per dispositivo mobile punto più sul servizio di ricerca del negozio con il telefono, gli orari e tutte le informazioni necessarie per raggiungere il punto vendita velocemente; solo in un secondo momento cerco di coinvolgere l’utente da un punto di vista di prodotto/catalogo.

Solamente comprendendo il contesto in cui si trova il nostro interlocutore possiamo capire quali servizi fornire e in che modalità erogarli.

In tal senso cercherò di impostare la Tabella 3.1 in modo tale che rappresenti il contenuto e il relativo ordine gerarchico del sito web standard e di due possibili ottimizzazioni e riordinamenti del contenuto stesso: una versione più simile al sito web desktop (m-site1) e una in cui i tagli di contenuto sono stati maggiori e più netti (m-site2):

Contenuto sito web desktop | Contenuto m-site1 | Contenuti m-site2

• Collezione

– Gallery

– Accessori

– Multimedia

• Negozi

• Profilo

– Filosofia

– Valori

– Storia

• Eventi

– News/Eventi

– Press

– Newsletter

• Vip Card

• Contatti

– Scrivici

– Dove Siamo

– Job

• Login

• Company info

• Negozi

– Vicino a me (apro GPS)

– Ricerca

– Scheda Negozio

• Contatti

– Scrivici (apro mail)

– Telefona (apro telefonata)

– Newsletter

• Eventi (solo news ed eventi)

• Vip Card

• Collezione

– Gallery

– Multimedia

– Accessori

• Negozi

– Vicino a me

– Ricerca

– Scheda Negozio

• Vip Card

• Collezione

– Gallery

– Multimedia

Tabella 3.1 – Contenuti e ordine gerarchico del sito desktop e due possibili ottimizzazioni m-site.

In entrambi i casi degli m-site utilizzerò degli accorgimenti molto semplici per sfruttare al meglio l’interattività dei dispositivi attraverso i quali sto navigando. In questo modo potrò attivare il GPS del telefono per proporre i negozi fisicamente più vicini all’utente che sta cercando in quel momento e lo utilizzerò anche per fornire indicazioni, a livello di mappe, sul modo più rapido per raggiungerlo. Inoltre eviterò l’utilizzo dei form nei contatti in quanto la loro compilazione con un telefonino è spesso un’impresa ardua; per tale motivo farò aprire il programma di posta elettronica dell’utente che potrà scrivermi in modo istantaneo e veloce. Inoltre sfrutterò la possibilità di creare una chiamata e quindi un contatto verbale con il mio interlocutore, dal sito web alla voce del cliente con soli due clic: questa è una vera rivoluzione della comunicazione digitale. Infine eviterò l’utilizzo di animazioni pesanti e complesse e della musica, presentando la mia collezione come gli utenti sono abituati a vedere le immagini sul telefonino, come fanno con Facebook o Instagram.

Il risultato finale dovrebbe essere come quello mostrato nella Figura 3.13.

Come si nota immediatamente, le homepage dello stesso sito web cambiano completamente se le visualizzo dal desktop o da uno smartphone. Se la vostra homepage rimane sempre la stessa, non state sfruttando assolutamente questa rivoluzione digitale.

Figura 3.13 – Confronto delle due homepage del sito Boggi®: quella desktop e quella ottimizzata per dispositivi mobili.

Caso studio Tgcom24

Per comprendere meglio quanto una mobile application possa essere decisiva e sinergica nella strategia di distribuzione del prodotto mediale e della comunicazione, analizziamo il caso studio di Tgcom24[25].

Tgcom24 è il portale di informazione multicanale e attivo 24 ore su 24 del gruppo RTI Mediaset (http://www.tgcom24.mediaset.it/) che fornisce notizie e altri approfondimenti testuali, video e fotografici in modo continuativo.

L’applicazione mobile di Tgcom24 è nata in seguito all’esigenza di offrire agli utenti un’informazione a 360 gradi, dove il lettore ha a disposizione contenuti sempre aggiornati e sempre disponibili alla consultazione.

La versione m-site del sito Internet aveva già soddisfatto in parte quest’esigenza, ma sfruttando le caratteristiche di implementazione e di fruizione delle app, Tgcom24 riesce a soddisfare in modo più completo la sua audience e a distribuire i propri contenuti attraverso canali prima inesistenti.

In generale, l’applicazione mobile è utilizzata in modo differente e complementare rispetto al sito Internet, sia desktop, sia m-site. Nel caso oggetto di studio di Tgcom24, la differente metodologia di fruizione dei contenuti, tipica della mobile application, permette all’utente di avere sempre la possibilità di consultare Tgcom24 per avere notizie aggiornate.

Tgcom24 offre quindi una versione desktop “standard” del sito Internet per chi accede da computer, mentre, per gli utenti in mobilità, fornisce due diversi prodotti: il sito web ottimizzato m-site, oppure l’applicazione. Entrambe le soluzioni permettono di accedere ai contenuti pubblicati dalla testata durante una situazione di mobilità e movimento. Infatti, come abbiamo già visto precedentemente, l’m-site è una versione del sito Internet adattata alla fruizione attraverso uno smartphone, mentre l’app permette di accedere ai contenuti pubblicati senza passare dal sito Internet, ma semplicemente cliccando sull’icona dell’app da smartphone o tablet. In questo modo è stato anche molto più semplice differenziare l’utenza degli smartphone rispetto a quella dei tablet poiché sono state realizzate due applicazioni distinte per le due famiglie di tipologie di dispositivi mobili.

Applicazione mobile e sito Internet sono sinergici e complementari e rendono l’esperienza dell’utente più completa. L’audience, infatti, conoscendo i diversi canali di distribuzione delle informazioni, ha la possibilità di scegliere quello più adatto al momento e alla situazione in cui si trova. Offrire più canali ai propri utenti è una forma di fidelizzazione del cliente che, avendo la possibilità di accedere ai contenuti di Tgcom24 in diverse situazioni della quotidianità, non ha l’esigenza di cercare notizie su un sito concorrente.

Inoltre, Tgcom 24, fornendo ai suoi lettori differenti strumenti con cui entrare in contatto con le notizie pubblicate, garantisce una continuità nell’esperienza dell’utente a prescindere dal device utilizzato durante tutto l’arco della giornata. Tgcom24 ha un layout grafico e uno schema di navigazione diversi a seconda del dispositivo connesso, per fornire la massima usabilità in ogni situazione, ma del tutto identici nel contenuto a prescindere dall’ambiente di distribuzione.

L’utente viene quindi fidelizzato, come detto, sul brand di Tgcom24, che è sempre presente su tutti i device utilizzati.

L’utilizzo di un sistema di Analytics di un unico fornitore permette una comparazione più precisa dei dati.

L’analisi del traffico Tgcom24.it e dell’applicazione sostiene le tesi sopra esposte. Infatti vediamo come gli utenti si spostino dal sito all’app, a seconda del momento della giornata o del giorno della settimana.

Come evidenziato nel grafico della Figura 3.14, e come spesso accade per i siti Internet in generale e per quelli editoriali in particolare, sul web il momento del picco di visite è il lunedì, mentre le visite scendono lentamente nel corso degli altri giorni della settimana per arrivare al weekend dove il traffico web si riduce notevolmente e considerevolmente. Per quanto riguarda la fruizione di contenuto attraverso l’applicazione, invece, il traffico rimane più costante durante tutti i giorni della settimana, presentando una linearità continua e, anzi, come si evince dal grafico, di domenica ottiene un picco di maggiori visite: l’utente non vuole rimanere senza informazione, ma la richiede on demand a seconda del dispositivo e della connettività che ha a disposizione.

Figura 3.14 – Comparazione visite desktop e sessioni app distribuite nell’arco della settimana (lunedì - domenica).

Anche l’analisi della distribuzione oraria delle visite presenta delle differenze sostanziali e sinergiche: il sito Internet inizia a registrare il proprio traffico attraverso un numero crescente di visite alle 9.00 circa. Le persone arrivano in ufficio, le visite continuano a crescere durante la mattinata e raggiungono un picco massimo nella pausa pranzo: sono gli utenti che mangiano la “schiscetta”[26] sul posto di lavoro. Successivamente, il traffico cala progressivamente, con un leggero incremento tra le 17.00 e le 18.00, che rappresenta un’ultima lettura al portale prima di uscire dall’ufficio; il traffico diminuisce drasticamente in serata a partire dalle 20.00. Le sessioni di utilizzo dell’applicazione, invece, sono complementari a quelle web e presentano delle dinamiche molto diverse. L’app viene lanciata molto presto la mattina, quando gli utenti si svegliano, durante una colazione veloce e sui mezzi di trasporto pubblici e privati mentre ci si reca sul posto di lavoro. È evidente, dal grafico della Figura 3.15, come al mattino il traffico dell’app avvenga molto prima rispetto al sito web; anche le app hanno un punto di massimo relativo durante la pausa pranzo; sono quelli che mangiano al di fuori del proprio luogo di lavoro o comunque distanti dalla propria postazione (per esempio, in una mensa aziendale). L’app di Tgcom24 è un ottimo commensale quando ci si trova da soli a mangiare in pausa pranzo.

Figura 3.15 – Comparazione visite desktop e sessioni app distribuite nell’arco delle ventiquattro ore (00-24).

Il traffico delle app resta poi costante durante tutto il pomeriggio, ma la sera, anche grazie ai tablet, il traffico dell’app di Tgcom24 esplode letteralmente. Prima con un breve picco intorno alle 20.00, in corrispondenza del prime time televisivo: gli utenti guardano il tg e le notizie via app invece di accendere la vecchia televisione e il fenomeno non si ferma al prime time. Inseguito, il traffico app raggiunge il punto di massimo assoluto alle 22.00. Mi trovo sul divano, non sono riuscito a vedere il tg in televisione (o non ho voluto farlo), tanto ora posso guardare on demand quello che mi sono perso. Il concetto dell’on demand è fondamentale per qualsiasi comunicazione editoriale: il consumatore moderno è abituato a essere al centro e a controllare direttamente la fruizione del contenuto. Fino a pochi anni fa vi erano molte persone che facevano di tutto pur di accendere la tv e non perdersi il telegiornale della serata: non per niente gli spazi pubblicitari prima, durante e dopo il tg (e il meteo) sono sempre stati tra i più costosi, sia per una reach più elevata, sia perché più visti dagli utenti. Oggi la situazione non è assolutamente la stessa: l’utente moderno sa che può rivedere quando vuole il telegiornale, nel momento in cui si sente pronto per farlo e senza dover rispettare un orario ben preciso; è lui che decide come, quando e che cosa vedere. Un altro parallelo esemplare è quello del meteo: personalmente sono stato fin da piccolo un fanatico delle previsioni meteorologiche, uno di quei piccoli geek che avevano anche una mini stazione meteo inchiodata fuori dalla finestra. Quando ero piccolo facevo di tutto per non perdermi almeno due appuntamenti con le previsioni del meteo alla televisione. Oggi ho una manciata di applicazioni meteo che uso più volte al giorno, quando voglio e senza più patemi d’animo: l’on demand mi ha reso più libero e più felice.

Questa complementarietà dei dati è dovuta al tipo di device che si utilizza per accedere ai contenuti online. Tra le 9.00 e le 18.00 l’utente è presumibilmente davanti al computer e naviga sul sito di Tgcom24 da desktop. Prima delle 9.00 e dopo le 18.00, invece, la situazione di mobilità ci porta a utilizzare smartphone o tablet per navigare; più che una questione di mobilità è una questione di comodità: il tablet è molto più uno strumento da divano che non un notebook.

Anche il dato delle sessioni di visita e di utilizzo dell’app dimostra la sinergia e la complementarietà in termini di comunicazione che si ottiene portando il contenuto su più canali.

Figura 3.16 – Comparazione con grafico a torta degli utenti unici giornalieri medi web e delle sessioni uniche giornaliere medie dell’app di Tgcom24. Fonte: RTI Mediaset. Dati: ShinyStat.

Il dato dei visitatori unici medi giornalieri mostra chiaramente che già il 17,45% degli utenti unici giornalieri accede in media ai contenuti di Tgcom24 attraverso l’applicazione e non via web. Questo significa che in media quasi un utente su cinque al giorno entra in contatto con il brand Tgcom24 attraverso l’applicazione. Considerando che la parte desktop di Tgcom24 è presente ormai da anni sul web e ha un’audience consolidata, mentre l’app è nata solo da qualche mese e presenta dei tassi di crescita di utilizzo incredibili, possiamo comprendere che questo fenomeno è in continua crescita esponenziale.

Il trend del dato è in deciso aumento, principalmente per due motivazioni: la prima è collegata alla diffusione di questi device, che sono sempre più comuni non solo tra gli utenti più avanzati ma anche tra quelli meno avvezzi all’utilizzo della tecnologia. La semplicità di utilizzo di questi strumenti ne agevola la diffusione: infatti, grazie alla tecnologia finger-touch, il processo di utilizzo delle caratteristiche più avanzate del device è più facile per gli utenti. La seconda motivazione della crescita del dato relativo al traffico proveniente da applicazione mobile è dovuta al fatto che la vita degli utenti scorre sempre di più in mobilità: siamo abituati a muoverci molto per i motivi più svariati, ma siamo anche abituati ad avere accesso a una mole considerevole di informazioni che troviamo sul web. Smartphone e tablet sopperiscono alla necessità di navigare in Internet e trovare le informazioni necessarie, anche quando non siamo seduti davanti a un computer connesso alla rete.

Per comprendere a fondo l’importanza di questi numeri e soprattutto la capacità di ulteriore sviluppo, ricordiamo che la diffusione di smartphone in Italia era ancora limitata e anche tuttora il mercato non è maturo, e si trova ancora in fase di espansione.

Figura 3.17 – Comparazione con grafico a torta delle visite web e delle sessioni app di Tgcom24. Fonte: RTI Mediaset. Dati: ShinyStat.

Passiamo ad analizzare anche la quantità di utilizzo di Tgcom24, dopo aver visto le quote degli utenti unici giornalieri. Ricordiamo che un utente unico giornaliero è un browser che accede al sito o un device mobile che utilizza l’app almeno una volta in un giorno. L’utente è unico giornaliero al primo accesso; visite o sessioni successive non vengono considerate per questa metrica. Le visite invece si sommano sempre anche nell’arco della stessa giornata.

Il dato relativo alle visite/sessioni ci aiuta quindi a comprendere ancora meglio come l’applicazione sia fruita dall’utente e quanto questa lo possa fidelizzare.

L’audience, in termini di sessioni di visita di Tgcom24, è veicolata per un quarto dall’app; infatti il 23,88% delle visite arriva dalla applicazione, mentre il 76,12% arriva dal sito Internet e dall’m-site.

Calcolando e confrontando il dato di frequenza di visita si può dedurre un’importantissima informazione: l’app di Tgcom24 fidelizza di più l’utente.

Per ottenere ciò, calcoliamo il rapporto tra il numero delle visite/sessioni e il dato dei visitatori unici giornalieri, ottenendo la frequenza di accesso al contenuto a seconda del mezzo per ogni singolo utente; calcoliamo che la frequenza di visita giornaliera da sito è circa 1,6 volte al giorno, ovvero, in media, gli utenti hanno visualizzato 1,6 volte ogni giorno il sito web di Tgcom24, mentre l’app ogni giorno viene lanciata 2,4 volte da ogni utente, sempre nello stesso arco temporale.

Ne consegue che tendenzialmente l’applicazione ha un 50% in più di capacità di fidelizzazione dell’utente rispetto ai canali tradizionali (frequenza di visita giornaliera di 2,4 rispetto a 1,6). Perché? Qual è il segreto dell’app? Come mai riesce a fidelizzare di più l’utente? Perché l’applicazione è contenuta nello smartphone che abbiamo sempre con noi a differenza del computer. Lo smartphone ci permette di connetterci con un clic, in assoluta rapidità, compatibilmente con la connessione, mentre il sito web via desktop non è sempre e comunque consultabile e disponibile: se sono in metro all’ora di punta schiacciato tra altri migliaia di pendolari, sarà difficile riuscire a trovare lo spazio fisico e contare sulla tolleranza dei miei compagni di viaggio per accendere il pc. Grazie allo smartphone, invece, posso consultare le ultime notizie anche dal vagone della metro modello scatola di sardine. Si noti inoltre che il traffico web in analisi comprende anche l’m-site: ciò fa comprendere ancora di più come la presenza di una icona sullo schermo di uno smartphone riesca a fidelizzare più di qualsiasi bookmark o impostazione di un browser web.

INTERVISTA A STEFANO GENOVESI, DIRETTORE MARKETING E SVILUPPO PRODOTTI MULTIMEDIALI DI RTI INTERACTIVE MEDIA GRUPPO MEDIASET SPA.

Domanda: Come è nata l’idea dell’applicazione?

Risposta: Il Tgcom nasce nel 2001 come testata giornalistica online. Dopo qualche anno, visto il successo conseguito sul web, nel 2009 decidemmo di declinarlo anche su mobile, con un’app inizialmente per il mondo Apple e poi per gli altri principali sistemi operativi.

D: Qual è l’obiettivo principale dell’app?

R: Mantenere l’engagement con i nostri lettori sul web anche quando sono in mobilità. Il tutto sempre in una logica free: i nostri siti nascono free ed è giusto che anche l’app derivata sia fruibile gratuitamente.

D: Qual è il modello di business sottostante?

R: L’advertising. Se negli anni scorsi questo modello di business era ancora in fieri, oggigiorno (e le ricerche di questi giorni del Politecnico lo confermano) la mobile advertising sta diventando sempre più importante e impattante.

D: Che cosa avete fatto per dare supporto all’applicazione? Sito web dedicato, social media marketing, advertising, SEO, SEA, campagne offline e online?

R: Più o meno tutto questo! Le attività di digital marketing oramai sono una conditio sine qua non per la riuscita di un sito o di una app.

D: Quali sono i risultati?

R: 3.600.000 download e punte di 5 milioni di utenti al mese che sono arrivati a “sfogliare” più di 150 milioni di schede.

D: Utilizzate un sistema di App Analytics per monitorare le performance della vostra applicazione?

R: Sì certo. Usiamo ShinyStat, che ci monitora e certifica il traffico.

D: In generale, vi ritenete soddisfatti dei risultati ottenuti? Che cosa avete fatto bene e che cosa male?

R: Sì, ci riteniamo soddisfatti. Forse, a essere pignoli, possiamo fare ancora meglio in termini di tecnologia per rendere sempre più user friendly le nostre app. E una volta di più confido sul boom degli investimenti pubblicitari sia su tablet sia su smartphone, così da contribuire a una svolta peraltro già avvenuta in altri Paesi.

D: Investirete ancora nei dispositivi mobili in futuro?

R: Assolutamente si! È oramai nel nostro DNA pensare quasi più al futuro che al presente.

21. Flash è un software Adobe che ha avuto un buon successo all’inizio del 2000, perché permetteva la creazione di animazioni grafche all’interno dell’Html. Questo linguaggio di programmazione (Actionscript) non è stato mai visualizzato dai dispositivi Apple e anche tutto il mondo Android, dopo un iniziale tentativo di lettura anche di Flash, ha abbandonato la visualizzazione di questo tipo di codice. Ciò signifca che qualsiasi pagina web contenga questa tecnologia viene visualizzata come una porzione di schermo vuota, al limite con un link che invita l’utente a scaricare il cosiddetto Flash Player. Un sito completamente in Flash, visualizzato da mobile, è una schermata monocolore, con il colore di sfondo impostato nell’Html.

22. Il traffco 3G è limitato a uno o due Gigabyte al mese, ma per coloro che non scaricano dal web e che vedono un numero limitato di video, è più che suffciente per navigare in rete usando applicazioni e funzionalità varie di Internet.

23. Il ranking potrebbe essere cambiato e dipende anche dalla vostra reale posizione geografca ed eventuali login di Google attivi, che personalizzano i risultati. Provate comunque, per curiosità, a cercare anche nella vostra località e ad aprire i primi risultati. Dovete sperimentare con senso critico e in prima persona l’usabilità per poterla comprendere.

24. Simpaticamente denominata “sindrome delle dita a patatine fritte”: le persone che hanno delle dita enormi faticano a centrare esattamente i punti dello schermo contenenti interfacce con pulsanti piccoli e vicini tra loro.

25. Ringrazio personalmente Stefano Genovesi, Direttore Marketing e Sviluppo Prodotti Multimediali di RTI Interactive Media – Gruppo Mediaset Spa, per la possibilità di utilizzo di questo caso studio.

26. Defnizione di “schiscetta”: il pranzo portato da casa e mangiato direttamente sul luogo di lavoro, spesso nella propria postazione davanti al pc.

CAPITOLO 4

PROGETTARE UN’APPLICAZIONE: DALL’IDEA AL PROGETTO

Idea, obiettivi, modello di business

Gli app store sono dei mercati decisamente affollati: esiste realmente una grandissima offerta di applicazioni. Apple App Store ha più di un milione di app a catalogo, Google Play altrettante e, come abbiamo già visto, sono stati sviluppati quasi due miliardi di mobile application.

Questi numeri ci fanno capire che la concorrenza è molto alta: avere una buona idea, sviluppare un’applicazione, metterla in un negozio e pensare che questa, magicamente, si diffonda in modo virale e abbia successo è come credere di comprare un biglietto della lotteria e vincere automaticamente il primo premio. È necessario quindi progettare il business in modo molto preciso e attento e solo successivamente a una profonda analisi del settore e dell’offerta già proposta decidere se proseguire o meno con lo sviluppo reale dell’applicazione: meglio un’attenta analisi iniziale, quando i costi sono veramente bassi, piuttosto che cominciare subito a investire nello sviluppo per accorgersi che stiamo facendo un’app esattamente identica a una già esistente.

Le persone acquistano software per risolvere dei problemi o per soddisfare delle necessità: il meteo ci permette di pianificare meglio le nostre giornate, i navigatori satellitari ci indicano la direzione corretta (quasi sempre), le liste cosiddette “to-do” (cose da fare) ci aiutano a rimanere organizzati, i giochi soddisfano la necessità di intrattenimento, il sentirci occupati in qualcosa. Questi sono bisogni generici e sono di facile individuazione, ma che cosa succede con bisogni più specifici?

Se stiamo pensando di sviluppare un’applicazione “non-gaming”, come quelle per la produttività o di utility, ci sono alcuni fattori che dobbiamo necessariamente tenere in considerazione.

Figura 4.1 – Una metafora dell’affollamento dei negozi delle applicazioni.

Per prima cosa dobbiamo verificare che il bisogno che la nostra app va a soddisfare non sia già risolto in maniera identica da qualche altra esistente sul mercato; visti i numeri precedenti, ovvero la quantità di applicazioni presenti sui vari mercati, spesso può succedere di trovarne già sviluppate in modo pressoché identico.

In secondo luogo dobbiamo chiederci se la nostra app soddisfi un bisogno in modo da rendere significativa l’esperienza mobile. È necessario che questo strumento sia diffuso via mobile e quindi utilizzato in movimento?

Infine, se la nostra applicazione, come spesso accade, dovesse risultare simile ad altre già esistenti, chiediamoci se ci sono funzionalità che possono essere aggiunte per soddisfare necessità a cui i competitor non hanno pensato e, nel caso i concorrenti siano pochissimi, proviamo ad analizzare quanto ritardo abbiamo maturato nei loro confronti e se e come i nostri competitor stanno supportando con azioni di comunicazione e di marketing la loro applicazione.

Secondo AdMob, network di mobile advertising, su 2.309 app[27] il 54% ha meno di 1.000 utenti, a dimostrazione di quante applicazioni abbiano pochi download e utilizzatori. Il fatto che un’applicazione venga distribuita in modo gratuito non garantisce comunque alcun successo o certezza sulla frequenza di utilizzo: un’applicazione è mediocre a prescindere dal fatto che non costi nulla.

Se poi l’app in questione è rilasciata a pagamento, deve per forza di cose soddisfare un desiderio o fornire un’esperienza nuova e utile, qualcosa per cui l’utente è disposto a pagare qualche centesimo di euro. Il prezzo delle app è comunque abbastanza irrisorio, se si pensa ai costi dei software per desktop, ma questo non le rende necessariamente degli acquisti automatici. È errato pensare che un utente possa acquistare un’app d’impulso solo perché costa qualche centesimo. Ricordiamo sempre che tutte le app all’interno degli store hanno dei prezzi relativamente contenuti, quindi la competizione sul prezzo è molto forte.

Il concetto è semplice, pensa a te stesso: non ci pensi due volte a spendere 3 euro per un cappuccino e una brioche, ma rifletti molto di più se comprare un gioco da un’app store a 2,99 euro. Questo avviene perché ormai il nostro smartphone è ricco di applicazioni, perché abbiamo superato la prima fase di novità, dove abbiamo fatto incetta di app, e ora pensiamo a quanto davvero ci possa servire, prima di comprarla e installarla sul nostro device, soprattutto in presenza di decine, se non centinaia, di app simili e alternative alla vostra. Un’offerta così ampia che va dal gratuito (o finto gratuito, con l’in-app purchase) a qualche euro rende molto meno emotivo e più ponderato l’acquisto, proprio perché il consumatore si trova di fronte a un’amplissima gamma di prodotti molto simili fra loro.

Una parte del problema relativo al prezzo risiede nel fatto che molte applicazioni, nel tentativo di aumentare le vendite e di scalare la classifica degli store per avere maggiore visibilità, vengono immesse sul mercato al prezzo minore possibile (per esempio: 0,99 euro). Questo fenomeno ha favorito una percezione distorta da parte degli utenti su quanto possa valere realmente un’applicazione.

Figura 4.2 – Un esempio di app simili rilasciate a prezzi simili con una guerra di prezzo al ribasso adottata da tutti i player.

Per superare queste “barriere di prezzo” la nostra app deve essere speciale, deve cioè soddisfare un bisogno esistente e portare l’utente a vivere un’esperienza unica.

Pensando al numero di app che sono già state sviluppate per tutti gli store, verrebbe da pensare che ne esista una per ogni tipo di necessità ed è davvero così, ma, periodicamente, esce un’applicazione che soddisfa un bisogno comune e diffuso e che ci fa esclamare. “Ma come ho fatto a non pensarci io!”. Per questo credo che ci sia ancora molto da progettare. I nostri bisogni sono continuamente in movimento e mutazione e di conseguenza lo sono anche le soluzioni.

Inoltre, non dimentichiamo che spesso le idee più brillanti sono le più semplici, quelle che prendono ispirazione da ciò che ci accompagna quotidianamente.

Come facciamo quindi a trovare un’idea che non sia ancora stata realizzata?

Iniziamo a pensare ai nostri bisogni, ai nostri interessi, alle nostre passioni. Non dimentichiamo mai che prima di essere sviluppatori siamo persone, siamo utenti! Esiste una funzionalità che abbiamo più volte invocato? Esiste una necessità che abbiamo riscontrato più volte per la cui soddisfazione avremmo voluto uno strumento preciso? Controlliamo che non ci sia già un’app sugli store e in questo caso pensiamo a come svilupparla noi. Nel mondo ci sono sicuramente altre persone come noi che hanno riscontrato lo stesso bisogno e che sono anche disposte a pagare qualche centesimo di euro per risolverlo; la scalabilità a livello globale delle applicazioni è enorme!

Nel caso in cui pensiamo a un mercato oppure a un’esigenza di nicchia, ricordiamoci che, in quanto tale, è popolata da pochi utenti (non sarebbe nicchia, altrimenti!), quindi il rischio è quello di sviluppare un’app molto importante e funzionale ma solo per pochissime persone. Ricordate che la nicchia può sempre essere espansa, senza però perdere la sua natura, come vedremo con due esempi pratici in questo paragrafo.

Un altro consiglio per favorire la ricerca dell’idea geniale potrebbe essere quello di guardare i nostri amici, i colleghi e i nostri familiari, cercando di osservare i loro bisogni e di capire come soddisfarli: in questo modo potrebbe arrivare l’illuminazione. Un consiglio che mi sento di dare è di stare molto attenti alla fonte della vostra idea in termini legali. Qualora sviluppaste un’app di successo in seguito agli input di qualcuno, quel qualcuno potrebbe un giorno chiedervi, giustamente o ingiustamente, un compenso per il fatto di avervi fornito un’idea: pensate sempre a come tutelarvi legalmente e fatelo prima che la vostra idea (o quella del vostro amico) abbia un successo planetario.

Non appena l’idea è definita, dobbiamo chiederci se il servizio che vogliamo offrire ben si presta alla declinazione mobile. Per quale motivo il nostro potenziale utente dovrebbe utilizzare l’applicazione in versione mobile e non preferirne magari una desktop? Il modo migliore per rispondere a questo tipo di quesiti è ancora una volta quello di immedesimarsi nell’utente e nel contesto di utilizzo della nostra app. Dobbiamo pensare se la nostra idea rappresenta una risposta a un bisogno che solitamente si riscontra in mobilità. Molto spesso, in seguito a una ricerca iniziale, capiterà di trovare applicazioni già presenti sul mercato quasi identiche alla nostra idea; nel caso in cui il numero di app identiche sia superiore a poche unità, personalmente consiglio di abbandonare l’idea dello sviluppo.

Figura 4.3 – Un esempio di app identiche: la torcia; abbandonate questa idea.

Mi spiego meglio: se per esempio avete intenzione di sviluppare un’applicazione che renda il telefono una torcia, facendo un rapido giro sugli app store vi renderete conto che ci sono decine e decine di app simili. Il mio consiglio è quello di cambiare idea i costi in termini di comunicazione e marketing per introdurre l’ennesima app torcia all’interno degli store e sperare di avere successo saranno certamente superiori ai ricavi e otterrete quasi certamente un ROI negativo. L’unica eccezione, sempre seguendo l’esempio della torcia, è il caso in cui voi siate un’azienda produttrice di pile ricaricabili, coltellini svizzeri e similari; in tal caso, l’ennesima torcia gratuita, sviluppata a bassissimo costo, sarebbe tollerabile.

Un altro dato, in un certo senso sconcertante e scoraggiante, che ci deve fare riflettere è quello che oltre la metà delle applicazioni scaricate sono utilizzate meno di 5 volte e poi cancellate da parte dell’utente. Non bisogna chiedersi solo perché una persona dovrebbe scaricare la propria applicazione, ma bisognerebbe ancora più insistentemente chiedersi perché un utente dovrebbe utilizzare la vostra applicazione più volte e, soprattutto, perché non dovrebbe cancellarla dal proprio dispositivo.

La strategia iniziale, quindi, diviene quasi più importante dell’idea[28].

La strategia d’azione deve partire dal concetto stesso dell’applicazione. Può sembrare banale ma è sempre bene domandarsi se l’idea che ci è venuta in mente risponda e soddisfi una reale necessità dell’utenza: stiamo proponendo una soluzione per un bisogno collettivamente sentito? Siamo sicuri che l’idea per la nostra app sia frutto di una necessità percepita? La ricerca delle nicchie è ottima, ma il fossilizzarsi in ambiti molto ristretti e piccoli può limitare la diffusione della nostra applicazione.

Inoltre, nella definizione della strategia di business per lo sviluppo di un’applicazione mobile, è bene chiedersi se il bisogno che stiamo cercando di soddisfare con la nostra idea ha la necessità di essere risolto in mobilità. Bisogna chiedersi dunque se l’utente a cui ci stiamo rivolgendo ha un bisogno che può essere soddisfatto con un’app per mobile o potrebbe semplicemente risolvere il tutto con un’attività da desktop. Come faccio a capire se il target ha un bisogno mobile? Per rispondere a questa domanda bisogna capire in primo luogo il contesto di utilizzo della nostra applicazione e se la nostra proposta integra le funzionalità tipiche degli smartphone. Per comprendere meglio il concetto, guardiamo un esempio reale di una delle primissime applicazioni che hanno avuto un largo successo: Bump.

Figura 4.4 – Bump, una delle primissime app con enorme successo, lanciata nell’Apple App Store nel marzo del 2009.

Bump è un’app nativa ideata da David Lieb e sviluppata dalla Bump Technologies nel 2008, che offre la possibilità di scambiare contenuti “scontrando” fisicamente due telefoni cellulari. Viene pubblicata sull’App Store di Apple nel marzo del 2009 e nel novembre dello stesso anno viene lanciata una versione Android. L’idea e il funzionamento di Bump sono molto semplici e immediati: sfruttando la funzionalità dell’accelerometro e del GPS, contenuti nei device mobile, Bump permette di condividere, per esempio, i contatti della rubrica. Fondamentalmente, la possibilità di scambiarsi i contatti è già soddisfatta da strumenti come i biglietti da visita sia cartacei sia elettronici o tramite account social come Twitter o Linkedin; Bump aggiunge un vantaggio: la velocità di scambio. Lanciando l’applicazione e scontrando gli smartphone si accelera notevolmente il processo di scambio dei contatti. Avete dimenticato i biglietti da visita in ufficio? Non c’è copertura di segnale per inviare una v-card via mail? Se avete Bump, questi non rappresenteranno più dei problemi. Un’idea quindi molto semplice, ma molto mobile, perché il dispositivo è sempre con me. Se esiste già una rubrica all’interno, perché non rendere il tutto più semplice, immediato, veloce e sempre a disposizione? Bump risponde appunto a tutta questa serie di bisogni; la sua nascita immediata con i dispositivi mobili ha contribuito al suo successo. L’app è stata scaricata da 125 milioni di utenti e vengono scambiati circa 2 milioni di immagini al giorno attraverso l’app; l’azienda è stata capitalizzata con circa 20 milioni di dollari anche se sta ancora cercando un sistema, come spesso accade, per rendere profittevole tutto questo traffico e questa condivisione.

Figura 4.5 – Bump in azione.

L’idea quindi deve essere concepita e delineata anch’essa strategicamente: un buon metodo per creare un’idea in modo strategico è quello di non parlare e non concentrarsi sui propri prodotti e i propri servizi, bensì quello di comprendere meglio le passioni dei nostri clienti e della nostra nicchia.

Questo concetto di sviluppo di applicazioni in ottica di inbound marketing[29] è fondamentale nel caso in cui vogliate sviluppare un’applicazione strettamente correlata a un marchio aziendale: bisogna assolutamente appassionare i propri utenti.

Toccare la passione dei propri clienti permette una maggiore fidelizzazione con la propria app e con il proprio marchio, ovvero un utilizzo più prolungato e costante nel corso del tempo e, soprattutto, l’utente rifletterà molto di più prima di cancellare la vostra applicazione dal proprio dispositivo.

Cerchiamo di comprendere esattamente questo processo di sviluppo strategico dell’idea per la realizzazione di applicazioni che siano “orientate all’utilizzo” e non semplicemente “orientate al download”. L’idea su cui si basa tutta la strategia deve essere quindi idonea per soddisfare una necessità di utilizzo in mobilità. L’idea, però, deve anche essere supportata da una serie di funzionalità e “sotto-idee” corollarie, che rendano la nicchia più ampia e fidelizzino l’utente attraverso servizi, utilità e passioni. Spieghiamo attraverso due esempi pratici questa fase strategica, che è estremamente importante.

Caso pratico 1: produttore di sci

Immaginiamo di essere un produttore di sci che vuole sviluppare un’applicazione con l’obiettivo di fare brand awarness in modo nuovo e con nuovi strumenti. L’idea non deve basarsi sul proprio prodotto; non devo quindi pensare a un’applicazione catalogo dei miei sci; l’idea si deve basare sulla passione che i miei clienti hanno nell’utilizzo del mio prodotto: sciare. L’azienda decide quindi di sviluppare un’applicazione per il tracking GPS della mia giornata sugli sci; offro un servizio a tutti, non solo ai miei clienti, ma a chiunque abbia la passione dello sci: la base dell’inbound marketing.

Cerchiamo quindi ora di vedere come ampliare strategicamente questa idea sfruttando al massimo la sensoristica di bordo del dispositivo mobile, ottenendo e acquisendo dati attraverso il dispositivo.

Figura 4.6 – L’idea iniziale della mia app: il tracking in una giornata di sci.

Partiamo quindi dalla nostra idea e dal nostro obiettivo di base: fornire un’applicazione che, una volta lanciata, permetta di registrare tutti i miei spostamenti durante una giornata intera di sci. Dovremo integrare la nostra app in modo nativo con il dispositivo, in particolare con il segnale del GPS, la bussola, l’accelerometro e le mappe di bordo, in modo da ottenere con precisione la posizione, la velocità e l’altitudine per calcolare tutte le metriche di spostamento e comprendere a fondo il contesto, come quando il nostro utente è fermo, quando sta scendendo e quando invece risale le piste attraverso gli impianti di risalita. L’obiettivo inoltre è quello di fornire la “registrazione” di tutta la giornata di sci; dovremo quindi sfruttare in modo intelligente i sensori del dispositivo per rendere il più efficiente possibile l’utilizzo della batteria e la sovrapposizione di altre applicazioni come le telefonate, gli sms ecc.

A questo punto cominciamo ad ampliare l’idea iniziale inserendo altre funzionalità e sezioni che arricchiscano l’applicazione, ma che siano anche propedeutiche alla diffusione virale e sociale della stessa e che evitino il più possibile la cancellazione dell’app da parte dell’utente.

SEZIONE ALBUM FOTO E VIDEO

Figura 4.7 – Prima idea di espansione dell’app con l’aggiunta di album foto & video.

Integriamo l’applicazione con la fotocamera del dispositivo e “tagghiamo” le immagini con il GPS. In questo modo potremo fornire non solo un album foto e video, ma anche l’esatta posizione in cui è stata scattata l’immagine. Integrando questa funzione all’interno delle mappe, potremo far vedere all’utente, anche in futuro, dove era posizionata un’immagine, un po’ come se le nostre foto e i nostri video fossero dei post-it sulla nostra mappa: dov’era quel salto che avevo fatto? Da dove si vede questo panorama? Il tutto fruibile anche per un utilizzo futuro.

SEZIONE E FUNZIONALITÀ SOCIAL & GAME

Figura 4.8 – Seconda espansione dell’idea per la soddisfazione dei bisogni social dei miei utenti e inserimento di un sistema di gamification.

Colleghiamo il più possibile l’applicazione ai social network: gli utenti della nostra applicazione sono il nostro primo veicolo marketing di diffusione della stessa; questo è un concetto da tenere sempre presente. In questo caso gli utenti potranno quindi pubblicare tutte le proprie statistiche e condividerle attraverso i canali sociali. Questo genererà curiosità all’interno della cerchia sociale dei nostri utenti e una potenziale diffusione virale dell’applicazione: una persona vede pubblicati i dati di un suo amico su Facebook raccolti grazie alla nostra applicazione e, poiché anche lui è un appassionato di sci, molto probabilmente scaricherà l’app che sta usando il suo amico. È dimostrato da numerosi studi che il consiglio di un servizio/prodotto ricevuto da un soggetto alla pari (cosiddetta relazione personale) ha un impatto enormemente maggiore rispetto alla medesima comunicazione ricevuta dall’alto e/o da soggetti terzi (cosiddetta relazione impersonale). Con l’applicazione, i nostri utenti potranno anche lanciare automaticamente delle sfide sui propri profili social: battere la velocità massima, il numero di ore sugli sci, la distanza percorsa ecc. La creazione di sfide e di classifiche stimola una forte diffusione virale dell’applicazione[30].

Ampliamo ulteriormente l’idea aggiungendo la sezione Utilità.

SEZIONE UTILITÀ

Figura 4.9 – Terza espansione dell’idea e introduzione della sezione Utilità.

Possiamo aggiungere una sezione di utilità: in primo luogo inserendo una serie di numeri telefonici di emergenza, con la possibilità di aggiungerli alla propria rubrica dei contatti del telefono e soprattutto permettendo la chiamata in modo diretto e immediato al numero attivato all’interno dell’applicazione. Aggiungiamo inoltre servizi di terze parti e/o interfacciamoci direttamente con applicazioni di terze parti di meteo e bollettini neve. Cerchiamo di fornire in modo preciso, dando un valore redazionale, gli orari e i numeri di telefono utili degli impianti a seconda della localizzazione del GPS. Continuiamo a espandere il progetto: in montagna ho bisogno anche di riposare e di un bombardino per riscaldarmi, quindi inseriamo la sezione Rifugi.

SEZIONE RIFUGI

Figura 4.10 – Quarta espansione con l’inserimento dell’elenco dei rifugi.

La sezione dei rifugi potrebbe diventare una sorta di vero e proprio “TripAdvisor degli sciatori”. Con uno sforzo redazionale iniziale potremmo fornire tutta una serie di informazioni molto utili per lo sciatore: oltre chiaramente all’ubicazione del rifugio con le coordinate GPS e ai modi per raggiungerlo integrati sulla mappa, lo potrei integrare con i social network, soprattutto con quelli più orientati al concetto locale, come 4square. Renderemmo possibile la recensione del rifugio da parte degli utenti con i commenti sulla qualità del servizio, prezzi, giudizi ecc. In un futuro potremmo pensare di coinvolgere gli stessi proprietari dei rifugi, che potrebbero avere un buon interesse a “ingaggiare” gli utenti che utilizzano la nostra applicazione per attività di marketing locale e couponing, per esempio. Il coinvolgimento dei proprietari delle strutture in modo diretto potrebbe essere una base per la creazione di un’applicazione dedicata a queste funzionalità: da un’applicazione, misurando l’effettivo utilizzo e interazione, può nascere addirittura un’altra applicazione.

SEZIONE SALVATAGGIO

Figura 4.11 – Quinta espansione dell’idea con le personalizzazioni e i salvataggi di tutte le informazioni.

Infine cerchiamo di soddisfare le esigenze di personalizzazione e soprattutto permettiamo all’utente di salvare (e magari anche di esportare) i propri dati e le proprie informazioni: aggiungiamo quindi per concludere anche delle personalizzazioni e delle funzionalità di salvataggio di tutte o quasi le informazioni presenti all’interno della nostra app.

Salviamo tutte le informazioni registrate, integriamole con il calendario e permettiamo agli utenti di esportare e trasferire tutte queste informazioni nel maggior numero di modi e formati possibili. Un numero elevato di informazioni salvate e interessanti crea un duplice meccanismo positivo: l’utente accederà con maggior frequenza a queste informazioni nel corso del tempo e, contemporaneamente, sarà meno propenso alla cancellazione dell’applicazione in quanto, cancellandola, perderebbe anche tutte le informazioni e statistiche storiche salvate.

La nostra applicazione deve essere una sorta di “diario dello sciatore”, che si basa sulla passione per lo sci, non sul nostro marchio di sci, e che permette un contatto continuativo nel corso del tempo e in un contesto estremamente positivo del mio cliente potenziale, un investimento in termini di inbound marketing enorme, con una semplice applicazione.

Risultato finale? Un’applicazione completa per qualsiasi appassionato di sci che cerchi non solo di fornire delle funzionalità base motivo del download iniziale dell’applicazione, ma che cerchi di ingaggiare l’utente in svariati modi e di diventare una parte integrante dei propri ricordi delle giornate di sci. In questo modo non otterrete solo download ma anche tanti utilizzi e pochissime cancellazioni, così che la vostra app di sci sarà presente ancora sullo smartphone anche sotto l’ombrellone, in attesa della prima nevicata stagionale, per essere poi rispolverata e per confrontare le proprie prestazioni con gli amici e con lo storico salvato nell’app stessa.

Un’applicazione che si avvicina abbastanza alla nostra idea espansa è l’app iSki Tracker.

Figura 4.12 – Dettaglio del tracking di una giornata di sci all’interno dello ski diary.

Nell’esempio personalmente testato della Figura 4.12, potete osservare il dettaglio del tracking di una giornata di sci: l’applicazione visualizza la data e la località della giornata di sci, i chilometri di piste in discesa e il relativo dislivello totale percorso, il numero di impianti di risalita che abbiamo utilizzato e quanti chilometri abbiamo percorso su seggiovie, funivie, skilift e quant’altro e chiaramente la durata totale, la velocità media, quella massima e il punto più elevato raggiunto[31].

Figura 4.13 – Mappa del percorso effettuato nel corso della giornata di sci.

Le stesse informazioni possono essere chiaramente visualizzate anche su una mappa che ci mostra tutto il percorso fatto e rende ogni sciatore orgoglioso della stanchezza delle proprie gambe (Figura 4.13).

E lo stesso percorso viene visualizzato anche su un piano cartesiano con le varie altimetrie raggiunte per i fanatici dei numeri e dei dislivelli (Figura 4.14).

Il tutto viene chiaramente salvato e archiviato, con il numero di giorni di sci, il totale di tutti i dati precedenti e la possibilità di accedere al dettaglio di ogni singola giornata: dallo skipass alla skipapp (Figura 4.15).

Figura 4.14 – Grafico altimetrico del percorso effettuato nel corso della giornata di sci.

Figura 4.15 – Lo ski diary di iSki Tracker: tutte le informazioni vengono salvate e così creo un vero e proprio diario delle mie giornate di sci.

Una cosa che potete notare nella parte bassa della Figura 4.15 è la presenza immediata di un pulsante arancione molto ampio e facilmente cliccabile per cominciare a registrare la giornata di sci, ma anche di altri tre pulsanti molto evidenti per il dettaglio dei giorni, soprattutto per vedere le attività degli amici con i quali mi sono collegato e la posizione in molte classifiche (per durata, km percorsi, velocità) di altre persone nello stesso comprensorio sciistico, così come i top skier nelle varie località.

Caso pratico 2: produttore di alimenti per neonati e bambini

Immaginiamo ora come secondo esempio di essere un’azienda che produce alimenti per neonati e bambini. Anche in questo caso non devo pensare di sviluppare un’applicazione collegata in modo diretto ai miei prodotti, ma devo pensare alla passione nell’utilizzo dei miei prodotti: i miei clienti non sono appassionati di pappette e omogeneizzati, ma del loro neonato. Focalizziamo quindi l’attenzione sulla passione (sul neonato) e decidiamo di creare un’applicazione per la misurazione dei percentili di crescita e peso del neonato[32].

Figura 4.16 – L’idea iniziale della mia app per il controllo della crescita del peso e dell’altezza del neonato.

Partiamo anche questa volta dalla nostra idea di base e centrale: un’app che riporti i grafici e le tabelle delle curve di crescita; inserendo la data di nascita del neonato e del bambino, la nostra applicazione fornirà la posizione di crescita sul grafico. Questa posizione potrà essere salvata per disegnare la curva di crescita personalizzata del neonato e del bambino all’interno del grafico. Dovremo quindi sfruttare a fondo le funzionalità touch e l’interattività dei dispositivi durante la visualizzazione dei grafici e delle tabelle. Aggiungiamo anche in questo caso un album di fotografie e di video.

SEZIONE ALBUM FOTO E VIDEO

Figura 4.17 – Prima idea di espansione dell’app con l’aggiunta di album foto & video.

Anche in questo caso interfacceremo l’applicazione con la fotocamera dei dispositivi, memorizzando la data e l’ora dell’immagine o del video. In questo modo potremo inserire le foto all’interno dei grafici rendendoli interattivi, ma anche colorati, così come potremo inserire e creare un vero e proprio album fotografico della crescita del neonato e del bambino nel corso del tempo: dalla scientificità del numero e del grafico alla poesia dell’immagine e della fotografia.

Ampliamo ulteriormente la nostra app aggiungendo anche la sezione Agenda.

SEZIONE AGENDA

Figura 4.18 – Seconda espansione dell’idea con l’inserimento dell’utilissima sezione Agenda.

La sezione dell’agenda è estremamente interessante per l’utente, perché uno smartphone è praticamente sempre con noi. L’agenda del neonato e del bambino è una sezione integrata con il calendario del dispositivo che sfrutterà le notifiche in push in modo intelligente. Gli utenti potranno segnarsi tutti gli appuntamenti di routine col pediatra, così come tutte le date delle vaccinazioni e dei relativi richiami; i dispositivi avvertirannocon delle notifiche l’utente qualche giorno prima per ricordare l’appuntamento e scatteranno degli allarmi anche all’avvicinarsi dell’evento. In questo modo potremo memorizzare la vita sanitaria del neonato e del bambino e averla a disposizione sempre con noi nel corso del tempo e ovunque. Pensiamo per esempio se nostro/a figlio/a in vacanza si dovesse tagliare con del ferro arrugginito: sapremmo immediatamente la data dell’ultimo richiamo della vaccinazione antitetanica, un’informazione che spesso viene tenuta in un cassetto a casa.

Incrementiamo ulteriormente l’app con un altro contenuto che potremo inserire in una sezione di consigli.

SEZIONE CONSIGLI

Figura 4.19 – Terza espansione dell’idea e introduzione della sezione Consigli.

Aggiungiamo una sezione più editoriale dedicata ai consigli e alle informazioni utili durante la crescita. Anche in questo caso, partendo dalla data di nascita, posso ottenere i consigli suddivisi per età e per tipologia. Sfruttando le possibilità di ricerca semantica del dispositivo, posso offrire una vera e propria guida tascabile e operativa. Possiamo inserire delle informazioni sulle tappe evolutive e collegarle con i sensori dei dispositivi per ottenere l’acquisizione personalizzata: così l’utente potrà scattare la foto dei primi passi e collegarla a quello step evolutivo, piuttosto che la foto della prima mela; potrà anche registrare con il microfono le prime parole e collegarle al relativo step evolutivo e così via. L’interazione e personalizzazione sono sempre molto importanti per aumentare la lunghezza di vita della propria applicazione.

Arricchiamo la nostra idea con un ulteriore contenuto interessante per la crescita e per aumentare il ciclo di vita di utilizzo della nostra applicazione con la sezione editoriale delle ricette.

SEZIONE RICETTE

Figura 4.20 – Quarta espansione dell’idea con l’arricchimento della sezione Ricette.

Occupandoci di alimentazione per neonati e bambini, non poteva mancare questa sezione. Cerchiamo di sfruttare comunque il dispositivo in modo da non creare un mero ricettario sfogliabile, ma qualcosa di più interattivo e coinvolgente. Le ricette potranno essere ricercate per età e fase di crescita, ma anche per ingrediente. Verrà fornita una serie di consigli e informazioni nutrizionali, potrà esserci una serie di video ricette in modo da rendere più semplice la loro comprensione. I nostri utenti potranno aggiungere anche le loro ricette personalizzate e potranno condividere tutto sui loro canali sociali.

Anche in questo caso soddisfiamo le esigenze dell’attività social e di gamification; nel bene o nel male, a prescindere da come la pensiate (si potrebbe scrivere un libro al riguardo), Facebook è pieno di foto di pancioni e neonati con resoconti puntuali e veri e autentici diari di crescita di neonati che non sanno ancora che cosa sia un social network, ma che si troveranno già account attivi e creati dai genitori socialdipendenti[33].

SEZIONE E FUNZIONALITÀ SOCIAL & GAME

Figura 4.21 – Quinta espansione dell’idea con l’aggiunta delle funzionalità sociali e di gamification.

Permetteremo agli utenti di condividere qualsiasi cosa e tutti i risultati di crescita del proprio neonato e bambino sui canali sociali; anche in questo caso veicoleremo l’adozione dell’applicazione da parte di altri utenti con le medesime necessità. Aggiungeremo anche alcuni piccoli e semplici mini game, preferibilmente classificati per fascia di età, con i quali potremo far interagire i piccoli.

Anche in questo caso il salvataggio di tutte le informazioni personalizzate e acquisite, dal grafico con la propria curva personale all’agenda con le date delle vaccinazioni, renderanno meno cancellabile l’applicazione, in quanto contenente informazioni importanti e uniche.

L’elaborazione e l’allargamento strategico dell’idea sono quindi un momento iniziale fondamentale. Bisognerebbe sempre schematizzare anche graficamente tutto il processo di elaborazione cercando di coinvolgere tutto il team del progetto fin da questo momento: ogni persona, dal grafico al programmatore, semplicemente pensando al proprio modo di agire quotidiano, potrebbe fornire dei contributi decisivi in questa fase. Una volta definito il tutto, dovremmo ottenere degli schemi di elaborazione iniziale delle idee come i seguenti.

Per quanto concerne l’applicazione per il tracking della giornata di sci, dovrei avere uno schema simile a quello della Figura 4.22.

Per quanto riguarda invece l’applicazione per le curve di crescita del neonato e bambino, guardate lo schema della Figura 4.23.

Figura 4.22 – Schema per l’ampliamento dell’idea iniziale di un’app per il tracking della giornata di sci.

Figura 4.23 – Schema per l’ampliamento dell’idea iniziale di un’app con le curve di crescita e di peso del neonato.

Analisi del mercato e della concorrenza

Abbiamo quindi strutturato la nostra idea, arricchendola con funzionalità e sezioni di contorno che la rendono molto utile. Prima di procedere con qualsiasi tipologia di sviluppo, conviene investire un po’ di tempo da parte del team di sviluppo per analizzare che cosa c’è già presente sul mercato e studiare uno a uno i concorrenti principali in modo continuativo.

È praticamente impossibile non avere applicazioni perlomeno simili a quella che abbiamo immaginato e schematizzato. Nel caso non ci sia proprio nulla, non deve essere automaticamente interpretato come un aspetto necessariamente positivo: se, dopo anni di esistenza degli app store, ancora nessuno ha fatto nulla al riguardo, forse è un’applicazione non realizzabile tecnicamente oppure è una vostra e unica esigenza personale; chiedete a un paio di conoscenti stretti che cosa ne pensano.

Procedere con lo sviluppo di un’applicazione senza nemmeno analizzare la concorrenza è un atteggiamento molto simile a quello di un kamikaze e potrebbe condurre a un clamoroso insuccesso fin dall’inizio: pensiamo per esempio a un’applicazione già sviluppata con l’intento di venderla e ci accorgiamo, solo una volta pubblicata, che nello store ne esistono già alcune identiche e simili che vengono distribuite gratuitamente. Non smetterò mai di ripetere che pensare di fare un’applicazione, pubblicarla negli store e che questa, magicamente, inizi a essere scaricata dagli utenti, è come credere di inserire un video su YouTube e che questo abbia automaticamente milioni di visualizzazioni.

Per comprendere meglio il momento e la situazione in cui versa il mercato delle applicazioni, è molto utile fare un parallelismo tra il boom dello sviluppo di applicazioni e quello della realizzazione di siti web. Quando c’è stata l’esplosione di Internet, molte aziende, chi prima chi dopo, hanno iniziato a comprendere l’importanza di avere uno spazio aziendale sul web e conseguentemente a incrementare la domanda di realizzazione del sito. Per gli sviluppatori di siti Internet, l’occasione non era affatto trascurabile e si è intravista la possibilità di incrementare facilmente il fatturato. In realtà i guadagni possono essere reali solo quando i progetti sono sostenuti da professionalità e strategia, due componenti fondamentali se si vogliono raggiungere risultati positivi. Le web agency che hanno incontrato questo incremento sensibile della domanda si sono dovute “armare” di competenze per riuscire a guadagnare davvero e per emergere rispetto alla concorrenza. Per il mercato delle applicazioni il discorso è molto simile. Le aziende percepiscono l’importanza di avere canali di comunicazione mobile e le occasioni di profitto per gli sviluppatori sono molte. Non pensiamo però che la realizzazione di queste occasioni sia facilmente attuabile se non abbiamo compreso l’importanza di definire la strategia del progetto prima di iniziare la realizzazione dello stesso.

I mass media e la rete hanno contribuito a generare questo pensiero di successo facile e veloce poiché spesso presentano casi reali vincenti, ma raramente commentano le migliaia di casi di insuccesso. Le applicazioni di successo più eclatanti vengono spesso portate alle luci della ribalta dai media, ma non siamo tutti Zuckerberg e non tutti abbiamo idee tanto rivoluzionarie quanto quella del social network Facebook. Di sicuro, però, tutti possiamo applicare il metodo e impegnarci per cercare un’idea innovativa. Basta tenere a mente che la strategia di marketing va pensata prima del lancio del prodotto. Pensiamo all’applicazione come un veicolo marketing, uno strumento strategico che ci permetterà di raggiungere gli obiettivi individuati.

Tornando al mercato delle mobile application, ammettiamo che la concorrenza è alta e di conseguenza i player non possono pensare di entrarvi senza una strategia ben studiata e pianificata. Per un progetto vincente è necessaria, oltre all’idea innovativa, anche l’analisi dei concorrenti e delle loro strategie.

Per prima cosa dobbiamo quindi avere un’idea. Abbiamo pensato alle nostre passioni, alle nostre necessità, a quello che da consumatori riterremmo essere un buon progetto. La tecnica di immedesimarsi nell’utilizzatore finale è vincente in quanto si assume un approccio critico che aiuta a sciogliere eventuali nodi e ad ampliare il punto di vista iniziale. Per allargare il bacino di utenza abbiamo riflettuto sugli aspetti di nicchia accessori e corollari all’idea principale.

Come abbiamo già visto nell’esempio dell’applicazione per il monitoraggio della crescita di un neonato, oltre alle informazioni sul peso e sull’altezza del bambino, si potrebbero integrare funzionalità relative all’alimentazione, alla salute o ai vaccini e molto altro ancora. Immedesimarsi nella figura dell’utente finale e, quindi, in questo caso, nei genitori del bambino, aiuta a rendersi conto di quali sono le informazioni davvero interessanti per l’utente e quindi a sviluppare un’idea più completa, che si differenzi meglio da altre app simili già presenti sul mercato.

ASO e analisi dei risultati degli app store

A questo punto ci troviamo con un’idea definita, innovativa e che risponde a un’esigenza in mobilità, quindi possiamo iniziare l’analisi della concorrenza. Ci spostiamo dunque sugli app store per fare una ricerca a livello concettuale: vediamo se qualcuno nel mondo ha già avuto la nostra idea. Dobbiamo assolutamente scoprire, prima di procedere con lo sviluppo, se sono già state sviluppate applicazioni simili o identiche a quella che abbiamo in mente. Abbiamo visto che la quantità di app che popolano gli store è ingente e le possibilità che la nostra idea sia già stata trasformata in mobile application sono relativamente alte. Avere un’idea innovativa che non è ancora stata tentata è abbastanza difficile, ma fortunatamente non impossibile; soprattutto lavorando sull’ampliamento del concetto iniziale di app, potremmo riuscire a differenziare la nostra app dai concorrenti rendendola molto più completa e con un ciclo di vita molto più lungo!

L’analisi della concorrenza deve essere svolta perlomeno sui due application store attualmente di maggiore successo: Apple App Store e Google Play; nel caso abbiate un po’ più di tempo, consiglio di guardare anche il negozio di app di Windows e quello nascente di Facebook, anche se in questo caso l’approccio dovrà essere più social e meno mobile. Un’app potrebbe essere stata sviluppata solo per un sistema operativo (il che potrebbe aprire scenari di business: perché questa app esiste per iOS ma non per Android? Posso svilupparla io? E via dicendo); è il caso per esempio di Instagram, che è stata pubblicata a diversi mesi di distanza prima per iOS e poi per Android.

Per una prima analisi della concorrenza avrete bisogno di tre semplicissimi strumenti di lavoro: un browser Internet, iTunes e un foglio di calcolo elettronico, tutti software gratuiti.

In primo luogo creiamo un file in formato .xls che ci accompagnerà schematizzando le varie informazioni sui concorrenti e rendendo l’analisi più semplice, confrontabile e misurabile.

Utilizzeremo il browser Internet per l’analisi dello store Google Play, mentre useremo iTunes per analizzare i concorrenti in ambiente iOS.

Così come nel web si parla molto di Ottimizzazione per i Motori di Ricerca (Search Engine Optimization: SEO), con il mondo delle applicazioni sta nascendo un nuovo mercato e un nuovo settore per l’Ottimizzazione degli app store denominata App Store Optimization: o più semplicemente ASO. Stanno fiorendo aziende specializzate nell’offrire visibilità alle applicazioni all’interno degli immensi mercati di distribuzione: la scelta delle keyword e il piano di comunicazione sono le prime fasi fondamentali per ottenere maggiore visibilità.

Cominciamo quindi a impostare, attraverso un file .xls, tutte le nostre parole chiave. Questa è un’attività ben conosciuta dagli esperti SEO del web che vi potranno dare indicazioni al riguardo. È importante però comprendere alcune piccole differenze fondamentali tra i motori di ricerca web e quelli degli app store. I search engine web come Google, Bing, Yahoo!, Yandex ecc. restituiscono i propri risultati organici in base ad algoritmi proprietari dei singoli motori molto complessi, che prendono in considerazione il contenuto semantico delle pagine web e la loro popolarità/autorevolezza a livello web a seconda di differenti fattori come link, segnali sociali, citazioni ecc. Definiamo il posizionamento organico, quello per il quale il sito che riceve il clic e la visita in seguito a una ricerca non deve pagare alcun corrispettivo al motore di ricerca stesso, a differenza dei risultati a pagamento che, come indica il termine stesso, pagano per ogni clic che ricevono in seguito a una ricerca.

Figura 4.24 – Esempio di risultati del motore di ricerca Google in seguito a una ricerca: evidenziati i risultati a pagamento e quelli organici.

Per quanto riguarda SEO e posizionamento dei siti web, sostanzialmente tutte le pagine di un sito Internet, attraverso il loro contenuto e la loro autorevolezza, concorrono al posizionamento. È come se il nostro sito web fosse una squadra di maratoneti, ogni pagina con la sua url ha la sua importanza a livello gerarchico e di autorevolezza e popolarità e può quindi arrivare tra i primi dieci corridori (ovvero in prima pagina su Google), sperando addirittura di vincere il primo premio. Il lavoro a livello SEO viene fatto su ogni pagina, con maggiore o minore intensità, come quando si allena un gruppo di atleti: si dedicherà maggior tempo ai campioni della squadra (la homepage, la pagina di categoria) e alle giovani promesse (una scheda prodotto molto ricercata), ma non si trascurerà l’allenamento SEO di ogni singola pagina e di tutta la squadra in generale. I motori di ricerca delle applicazioni funzionano in modo molto più “tradizionale” e, se vogliamo, alquanto più “stupido” rispetto a quelli web. Gli app search engine ricercano i propri risultati all’interno di un database (grande, ma molto più ridotto e meno complesso di quello per il web), basandosi su informazioni molto statiche e inserendo elementi di fruizione dal lato utente per mescolare i risultati: sostanzialmente un catalogo molto statico, dove i risultati vengono resi più dinamici attraverso l’influenza del numero di download e di recensioni generate da un’applicazione in un determinato lasso temporale. In particolare, il motore di ricerca dell’App Store di Apple basa la propria semantica in un modo attualmente semplicistico. Apple ha adottato alcune scelte molto rigide in termini ASO, che possono sembrare alquanto stupide viste dagli occhi di un SEO, ma questa strategia non è stata dettata tanto da una mancanza di competenze specifiche in ambito di ricerca quanto piuttosto dal fatto che queste semplificazioni portano a una maggiore possibilità di visibilità anche da parte di applicazioni appena sviluppate e neonate rispetto a quelle di maggiore successo; questo perché è praticamente impossibile dominare le ricerche di un settore di questo motore di ricerca, a differenza di quanto avviene per il web dove in alcuni settori (per esempio viaggi aerei e hotel), certi portali sono sempre presenti per ogni parola chiave di settore ed è molto complesso per un nuovo portale di voli aerei o di booking e recensioni di hotel posizionarsi nel breve periodo nelle primissime posizioni di Google.

A livello di app store non avremo quindi a disposizione i contenuti della nostra applicazione indicizzati ma semplicemente alcuni campi testuali estremamente limitati da compilare durante la fase di sottomissione dell’app all’interno dello store. Questo significa una maggiore e più accurata scelta delle parole chiave e, soprattutto, comprendere al meglio la priorità tra le stesse: non potremo distribuire decine o centinaia di keyword su altrettante pagine, ma avremo uno spazio limitatissimo di pochi caratteri; è fondamentale sfruttare e ottimizzare al massimo questo ridottissimo spazio. Non dobbiamo quindi più pensare a una keyword costituita da più vocaboli, per esempio “hotel a Venezia” che è una keyword di tre vocaboli, ma a una sola parola chiave: “hotel” e “Venezia”, che l’app store successivamente concatenerà in seguito a una ricerca di un utente.

Apriamo quindi il nostro file .xls; nel caso abbiate già esperienza SEO, vi consiglio di scrivere prima le keyword come se la vostra app fosse un sito Internet e poi di trasformarle in parole chiave per il negozio delle applicazioni. Dovreste ottenere una tabella formata da due colonne, come illustrato nella Tabella 4.1.

Questo foglio .xls sarà il nostro punto di riferimento per tutta l’analisi della concorrenza e potrà essere modificato in base a riscontri e idee che si possono ottenere analizzando i concorrenti.

Keyword “SEO” | Keyword “ASO”
Peso bambino | Bambino
Peso bambini | Bambini
Peso neonato | Neonato
Peso neonati | Neonati
Curve di crescita bambini | Peso
Curve di peso bambini | Curve
Alimentazione neonati | Crescita
Alimentazione neonato | Alimentazione
… | …

Tabella 4.1 – Esempio di trasformazione da keyword SEO a keyword ASO.

Una volta che abbiamo compreso che cosa potrebbe cercare l’audience per la quale abbiamo realizzato la nostra applicazione, possiamo impostare il foglio di analisi e monitoraggio della concorrenza suddiviso per singola lingua/mercato dove verrà distribuita la nostra applicazione che dovrebbe essere localizzata anche linguisticamente per le differenti aree geografiche che si intendono “conquistare”. Creiamo quindi, per la singola lingua, un file .xls con le colonne come quelle della Tabella 4.2.

Tabella 4.2 – File per l’analisi di app concorrenti.

Sviluppatore: il nome dello sviluppatore concorrente. Anche in questo caso il nome dello sviluppatore può cambiare nel corso del temp o perché è possibile da alcuni mesi la vendita di app tra uno sviluppatore e un altro.

Lingue: le lingue in cui è stata sviluppata l’applicazione da parte del nostro concorrente: questa informazione ci può dare un’idea dei mercati già maturi e profttevoli per la nostra app; guardando i mercati dei nostri concorrenti possiamo sfruttare una loro precedente analisi geografca dei mercati potenziali.

Prezzo: indicheremo a quale prezzo viene venduta l’app. Nel caso di applicazioni con “in-app purchase” segneremo il prezzo di ingresso del primo in-app purchase, o il prodotto con acquisto in-app offerto al prezzo più basso.

Note prezzo o in-app purchase: in questo campo testuale dovremo inserire delle note residuali che spiegano meglio le limitazioni della versione gratuita e gli incentivi per gli acquisti “in-app”. Nel caso di app completamente gratuite, indicheremo la presenza o meno di messaggi pubblicitari. Per quelle con in-app purchase aggiungeremo le principali voci di vendita e i relativi prezzi.

Categoria: la categoria primaria e secondaria dove è stata inserita quell’app. Ricordiamo che la ricerca per keyword mette a confronto le app di varie categorie, in quanto parte da una ricerca semantica e non di categoria. In tal senso i nostri concorrenti potrebbero appartenere a categorie diverse e possiamo comprendere meglio con quest’analisi in che categoria inserire la nostra.

# app in cat (numero di applicazioni nella categoria primaria/secondaria): la scelta della categoria può essere anche infuenzata dal numero di concorrenti presenti in una determinata sezione. Il numero di applicazioni presenti in quella categoria dà un’idea di quanto possa essere potenzialmente complessa la concorrenza in quella categoria stessa.

Prezzo medio: il prezzo medio delle applicazioni a pagamento in quella determinata categoria. Questo è un dato che si può ottenere molto facilmente per Google Play, mentre ci vogliono un po’ di pazienza e tanto lavoro manuale per lo store di Apple.

App > 50k Dl in cat: indica il numero di applicazioni che ha superato la soglia dei cinquantamila download nella categoria. Questo è un indicatore di interesse di categoria da parte degli utenti di quel negozio di applicazioni: se molte app superano tale soglia, ciò è un’indicazione di elevato bisogno e necessità di app per soddisfare questi interessi. Si pensi per esempio a quante app differenti hanno raggiunto questo traguardo nella categoria “giochi” o “meteo”. Anche questo è un dato facilmente ricavabile per le app con sistema operativo Android, mentre per il mondo Apple è molto più complesso. La cosa importante sono comunque i trend e le indicazioni relative, quindi l’analisi su app presenti in Google Play può essere utile anche se pensate di sviluppare, in un primo momento, solo per l’Apple App Store.

Download: questo è un campo di valutazione soggettivo, perché è molto complesso ottenere dei dati precisi sul numero di download di app concorrenti alla nostra. In base all’esperienza di chi sviluppa strategie, si può percepire il numero di download di una determinata app partendo dalla descrizione, dal numero di rating e recensioni ottenuti, nonché attraverso alcune ricerche di quell’app sul web e sui social. Per esempio, vedere il numero di “mi piace” presenti sulla pagina Facebook uffciale dell’applicazione. Attribuiremo un valore in una scala con 5 gradi variabili da “molto bassi” a “molto alti”. Infne cercheremo di sfruttare la maggiore apertura del mondo di Google Play per ottenere alcune informazioni che, indirettamente, sono valide anche nel negozio di app della mela morsicata.

Descrizione: in questo campo inseriremo la descrizione della nostra app concorrente. L’analisi della descrizione dei concorrenti è utile per comprendere meglio la loro idea di mercato e di bisogni che vogliono andare a colmare; la descrizione inoltre può fornire idee e indicazioni per ampliare e ordinare meglio il nostro foglio iniziale delle keyword. Infne, ci offre una panoramica generale delle funzionalità dell’app concorrente da tenere in considerazione anche per lo sviluppo della nostra idea.

Versione: inseriamo la data di rilascio dell’applicazione (ovvero il suo grado di anzianità) e il numero di versioni; app aggiornate di frequente normalmente sono di successo, app abbandonate alla versione 1.0, dopo tre anni indicano spesso il contrario. Tutti segnali da tenere in alta considerazione.

Update: in questa cella inseriamo tutte le nuove funzionalità sviluppate da quando è nata l’applicazione. Spesso le app vengono ampliate e sviluppate, in particolare quelle che ottengono un buon successo, anche in base alle informazioni inviate dagli utilizzatori agli sviluppatori. Leggere quindi le modifche e le nuove implementazioni signifca comprendere meglio che cosa gli utenti stessi vogliono che faccia una determinata applicazione e come lo dovrebbe fare. Quando leggete: “aggiunta indicazione del vento con bussola” in una app del meteo, molto probabilmente molti utenti avranno chiesto allo sviluppatore questa nuova funzionalità e anche come rappresentarla.

Rating: il punteggio attribuito dagli utenti a quella applicazione. La mancanza di rating per un’app presente nello store da oltre un anno è un indicatore di scarso successo, tanti voti per un’applicazione “giovane” indicano un buon successo in quel determinato mercato. Ricordiamo che il giudizio degli utenti deve essere sempre analizzato guardando in particolare l’ultima versione e soprattutto bisogna sempre leggerlo relazionandolo al prezzo di vendita dell’app stessa. Gli utilizzatori che pagano magari 3,99 euro per un’app si aspettano un prodotto di un certo valore e con determinate funzionalità come da voi descritte in fase di presentazione. Nel caso in cui l’app non rispetti le aspettative degli utenti, potrebbe ottenere dei giudizi molto bassi. Per contro, gli utenti possono premiare con dei bei giudizi delle app semplici ma gratuite, che svolgono in modo dignitoso i compiti per i quali sono state create.

Note Review: in questo campo incolleremo le recensioni più signifcative. Vi consiglio di suddividere ulteriormente i giudizi degli utenti in “positivi” e “negativi”; gli stessi store mettono a disposizione queste funzionalità di ordinamento delle recensioni stesse. I giudizi degli utenti offrono spunti e idee importantissime da capire già in fase di realizzazione della nostra applicazione; analizzarle puntualmente arricchirà in modo sostanziale il bagaglio di informazioni necessario per supportare tutta la strategia di sviluppo e di distribuzione della nostra app: non sottovalutate mai la voce degli utilizzatori.

Cominciamo quindi l’analisi della concorrenza per la nostra applicazione sulla crescita in altezza e peso dei neonati e dei bambini: iniziamo a condurla per ogni lingua in cui viene sviluppata. Per il momento non pensiamo che un’app in inglese vada bene per tutti i mercati. Iniziamo quindi a ricercare le parole chiave che abbiamo inserito a livello SEO (non ASO) in modo da simulare esattamente quello che appare lato utente. Inseriamo quindi le keyword “peso bambino”, “altezza bambino”, “peso neonato”, “altezza neonato” e simili, in ogni lingua, in quanto i risultati della ricerca sono molto diversi.

Grazie all’ottimizzazione per il motore di ricerca interno agli app store che faremo, saremo avvantaggiati nella ricerca di prodotti simili a quello che abbiamo in mente.

Figura 4.25 – Risultati su Apple App Store per la ricerca “altezza bambino”.

Figura 4.26 – Risultati su Apple App Store per la ricerca “peso neonato”.

Figura 4.27 – Risultati su Apple App Store per la ricerca “altezza neonato”.

Negli screenshot della pagina precedente possiamo vedere come, a seconda della keyword ricercata, le applicazioni che vengono proposte siano diverse; questo dipende dalla strategia di ottimizzazione dei risultati degli app store messa in atto dallo sviluppatore: sostanzialmente, per casi come questo dove non sono presenti centinaia di risultati, la scelta del nome dell’app e dei 100 caratteri per le keyword risulta fondamentale. In casi con pochi risultati riusciremo quindi a comprendere, con una banale corrispondenza inversa, quali siano state le parole chiave selezionate dai nostri concorrenti.

Guardiamo i vari concorrenti presenti nei risultati e cominciamo a compilare le varie colonne del nostro file .xls con il nome dell’app, dello sviluppatore e così di seguito. In base al numero di volte in cui compare un’app e a quello di download dell’app stessa, proviamo a ordinare il nostro file di analisi dai concorrenti di maggiore successo a quelli minori. Cerchiamo quindi la presenza di app ricorrenti nelle varie ricerche che eseguiamo partendo dal foglio delle keyword iniziale. Per esempio, l’app “Potito Crescita Infantile” è sempre presente tra i risultati con tutte le varianti di parole chiave provate. Una volta individuate le applicazioni più simili a quella che abbiamo in mente, scendiamo più in profondità nell’analisi, indaghiamo le informazioni contenute nella scheda di ogni prodotto e riportiamole nel nostro file .xls.

Figura 4.28 – Dettaglio generale della scheda all’interno dell’App Store di Apple di un’applicazione concorrente.

Si vede subito il nome della categoria in cui l’app è stata inserita, primo elemento fondamentale per comprendere il suo grado di concorrenza. Come già anticipato, la categoria ci serve per capire ancora meglio se l’idea dello sviluppatore è davvero assimilabile al nostro progetto, ma potrebbe anche essere in qualche modo fuorviante rispetto all’idea originaria. Per esempio, la già citata app Bump è disponibile nella categoria Social network, che non è esattamente la prima che viene in mente pensando alle funzionalità di Bump; ma è stato un elemento di successo in quanto Bump è riuscita ad affiancarsi ai brand importanti dei social network innalzando al tempo stesso anche il proprio brand: emergere tra nomi quali Facebook, Twitter, Linkedin e altri può essere, soprattutto adesso, un’impresa alquanto ardua, ma al contempo potrebbe risultare una strategia eccezionale. Se pensiamo che comunque le applicazioni contenute nella categoria Social network sono tendenzialmente conosciute e probabilmente già scaricate, la nuova e ancora sconosciuta Bump potrebbe attirare più l’attenzione tra quelle piuttosto che tra altre app poco note; una tecnica di comunicazione che all’epoca di Bump, dove erano presenti ancora relativamente poche applicazioni nella categoria Social network, è stata una scelta estremamente vincente.

Un altro elemento da riportare nel nostro file e da considerare è il prezzo: l’app che stiamo analizzando è gratuita o a pagamento? Magari esiste in versione lite gratuita e per avere la completezza delle funzionalità bisogna passare alla versione pro? Oppure il pagamento avviene durante l’utilizzo dell’applicazione ovvero il cosiddetto “in-app purchase”? E in tal caso, quali sono i prodotti/servizi più venduti nel processo in-app? Queste sono domande da porsi prima di decidere a quale prezzo vendere l’app o se al contrario si vuole rilasciarla gratuitamente.

Figura 4.29 – Dettaglio degli acquisti in-app disponibili di un’applicazione concorrente all’interno dell’App Store di Apple.

L’analisi della concorrenza potrebbe addirittura minare le convinzioni e il modello di business iniziale, ma anche dare idee e informazioni in modo da plasmare il modello di business stesso allo stato del mercato. Le possibilità da questo punto di vista sono diverse; come abbiamo visto, la scelta migliore dipende sicuramente da che tipo di prodotto stiamo lanciando sul mercato, da quanto possa essere conosciuto il brand da quanto possa essere innovativo il progetto.

Analizziamo e riportiamo poi il dato che indica l’ultima versione scaricabile. Come precedentemente accennato, è molto importante per capire quanto l’app sia seguita dallo sviluppatore che cerca di fornire un prodotto funzionante e attento alle necessità dell’utenza. Se un’applicazione viene “abbandonata” e non viene aggiornata, il rischio che corre lo sviluppatore è quello di perdere punti in reputazione a livello di sviluppatore e non di singola app, ma questo si potrebbe ripercuotere anche su altre app sviluppate successivamente: la scelta di abbandonare un’app che non riscuote il successo sperato è molto rischiosa e da ponderare con estrema attenzione.

Figura 4.30 – Dettaglio della versione e delle evoluzioni di un’applicazione concorrente all’interno dell’App Store di Apple.

Figura 4.31 – Dettaglio della versione e delle evoluzioni di un’applicazione concorrente all’interno dell’App Store Google Play.

Il successo di un’app può essere letto anche in relazione alle review lasciate dagli utenti. Una peculiarità degli store, infatti, è la componente conversazionale: ogni utente ha la possibilità di giudicare il prodotto con un sistema di rating a stelline, lasciando anche un commento a sostegno del voto. Nei commenti, spesso, gli utenti lasciano consigli più o meno espliciti su come implementare o migliorare l’applicazione. Oltre ai commenti sugli app store, è utile tenere monitorati anche i siti e i blog di settore dove gli utenti parlano dell’applicazione concorrente e creano dialogo e conversazioni intorno all’argomento. Lo sviluppatore deve imparare a fare tesoro di queste informazioni preziosissime per migliorarsi continuamente.

Figura 4.32 – Dettaglio delle recensioni degli utenti di un’applicazione concorrente all’interno dell’App Store di Apple.

Figura 4.33 – Dettaglio delle recensioni degli utenti di un’applicazione concorrente all’interno dell’App Store Google Play.

Il dato dell’ultima versione scaricabile dell’applicazione può essere letto anche in relazione a quanti consigli di miglioramento sono stati lasciati dagli utenti. Dal numero di versioni che sono state rilasciate si comprende sia l’attenzione dello sviluppatore, sia la reale usabilità dell’app.

Sempre nella scheda riassuntiva, possiamo vedere inoltre le lingue in cui è stata rilasciata la mobile application, un indicatore importante per comprendere quali siano i mercati più stimolanti, in base alla scelta dei concorrenti.

Un’ultima informazione che possiamo trarre dalla scheda è quella dei requisiti dove vengono indicati i device in cui quello specifico prodotto può essere installato, la compatibilità dell’app con i diversi strumenti come smartphone e tablet, e soprattutto quale versione del sistema operativo si richiede per far funzionare correttamente l’applicazione. Un’analisi completa di tutte queste informazioni relative a tutte le applicazioni concorrenti che abbiamo individuato dovrebbe a questo punto averci fornito un quadro della situazione abbastanza preciso e in grado di farci iniziare i lavori sul nostro progetto.

Ecco un esempio di file compilato nelle sue voci con un’analisi della concorrenza reale.

Tabella 4.3 – File per l’analisi di app concorrenti da compilare con i concorrenti principali della nostra app per il calcolo della crescita del neonato.

Compilare in modo corretto il file per l’analisi della concorrenza è fondamentale. Una volta finito, avrete certamente le idee molto più chiare su come dovete posizionare la vostra app e le difficoltà che incontrerete: in alcuni casi l’analisi vi farà desistere dallo sviluppo di un’idea e viene fatta anche per questo; in molti altri casi vi farà venire in mente tantissime idee e modalità di differenziazione rispetto ai concorrenti e sarete certamente più pronti a fronteggiare le difficoltà del vostro progetto e sul percorso che dovrete seguire.

L’importanza del nome e dell’icona

Abbiamo adesso un’idea chiara e precisa dell’applicazione che vorremmo sviluppare; l’abbiamo ampliata in modo corretto per attrarre una maggiore audience potenziale intorno all’idea/passione iniziale, abbiamo compreso e pensato le parole chiave con le quali i nostri utenti potrebbero colmare un loro bisogno e abbiamo fatto una prima analisi dei concorrenti: ora dobbiamo scegliere il nome e l’immagine rappresentativa della nostra applicazione.

Procediamo per gradi: pensiamo in primo luogo a come chiamarla. Il nostro obiettivo principale è quello di rendere il nome della nostra applicazione il più “memorizzabile” possibile. Pensiamo ad app di successo, escludendo quelle con un brand già molto noto; nella maggioranza dei casi le app diventate famose hanno un nome breve, composto da uno o due vocaboli, spesso di fantasia ma che evoca possibilmente un concetto già presente nell’immaginario collettivo. “Bump”: quattro lettere con un richiamo onomatopeico di due smartphone che si urtano tra di loro; “Shazam”[34]: sei lettere e un nome che evoca qualcosa di magico più che di musicale, proprio per la magia che sembra diffondere questa applicazione straordinaria; “Ruzzle”[35]: sei lettere, che ricordano la parola inglese, ma conosciuta a livello mondiale, di “puzzle”; un semplice cambiamento della prima lettera della parola, insieme alle dinamiche sociali di questo gioco, ha creato un vero e proprio brand conosciuto a livello mondiale; infine “Angry Birds”[36] o “Temple Run”[37]: due esempi di app con nomi a due vocaboli, ma molto stringati, di videogiochi pensati e sviluppati appositamente per i dispositivi mobili, che hanno avuto un enorme successo a livello planetario; casi possibili solo grazie alla nascita di un nuovo mercato videoludico all’interno dei negozi di applicazioni. Questi ultimi due brand sono stati sviluppati da aziende poco conosciute nel settore (dei granelli di sabbia in confronto a team enormi come quelli della Electronic Arts o della Valve) che sono riuscite a promuovere dei giochi nuovi con un successo incredibile anche a livello economico.

Figura 4.34 – Nomi e icone di app di successo: Shazam, Ruzzle, Temple Run e Angry Birds.

Il nome, insieme all’icona, rappresenta l’app: questi sono i due elementi che contribuiranno alla sua diffusione e che verranno comunicati sia all’interno sia all’esterno dell’app store. Un nome corto, indicativo, evocativo e memorizzabile agevola moltissimo il passaparola tra gli utenti nella prima fase; con poco budget a disposizione, sono proprio i vostri utilizzatori il primo veicolo di marketing della vostra applicazione. Se il nome è facilmente memorizzabile, sarà anche più facile che un individuo suggerisca a qualcun altro la nostra applicazione e che quest’ultimo se la ricordi: “Sto giocando a Temple Run da una settimana!” è più facile da ricordare rispetto a “Sto giocando a “Lost temple and a running hero” da una settimana!”.

Il nome deve essere in primo luogo corto: sostanzialmente, esiste una regola generale che ci insegna che non deve superare i 13 caratteri. Perché proprio tredici battute? Perché se guardate un qualsiasi dispositivo mobile iOS, i caratteri visibili al di sotto di ogni icona (sul telefono, sul tablet, in iTunes, ovunque) sono al massimo 13; nel caso in cui l’icona sia stata nominata con oltre 13 caratteri, non è completamente visualizzabile e il nome viene troncato con dei puntini.

Figura 4.35 – L’app Dizionario Inglese Italiano (Free): un esempio di applicazione il cui nome supera i 13 caratteri e viene troncato dai dispositivi iOS e che non presenta una vera identità di brand, ma un nome comune.

La regola dei 13 caratteri è ancora più importante in fase di ricerca delle applicazioni. Quando un utente cerca all’interno di un app store, ottiene una serie di risultati organizzati in listati (che variano in termini grafici e di esposizione da negozio a negozio). In generale, viene presentata una prima lista di risultati con poche informazioni, tra le quali spiccano il nome e l’icona dell’app: se il nome fosse più lungo dei fatidici 13 caratteri, non sarebbe immediatamente leggibile dal listato dei risultati; l’utente vedrebbe un nome parziale con dei puntini di sospensione che lo troncano: è un po’ come se i vostri prodotti presenti all’interno dei supermercati avessero tutti l’etichetta con il vostro marchio incompleto. Non lo accettereste mai. Non accettate situazioni nel mondo digitale che non fareste anche nel mondo analogico!

Figura 4.36 – L’app Dizionario Inglese Italiano (Free) compare troncata anche all’interno del listato dei risultati dell’App Store di Apple.

Un nome lungo e banale è il modo peggiore per cominciare un progetto di supporto all’app, a livello di comunicazione e di marketing: abbiamo già perso una buona parte di possibilità di far ricordare il nome dall’utente per il semplice fatto che è impossibilitato a leggerlo tutto!

Vediamo quindi di scegliere un nome che non superi i 13 caratteri, in modo da poterlo rendere interamente visibile e di conseguenza facilitarne la memorizzazione.

A questo punto, spazio alla creatività: possiamo scegliere una parola che identifichi l’azione principale dell’app, possiamo sceglierne una onomatopeica o ancora un paio di parole insieme. Nel caso si voglia un nome che descrive la funzionalità primaria dell’app, bisogna fare attenzione a non scegliere un nome troppo generico e banale; bisogna sforzarsi di cercare qualcosa di nuovo e creativo, qualcosa che emerga dal mare magnum di app simili alla nostra, o semplicemente della stessa categoria. Spieghiamo meglio con un esempio: se sviluppo un’applicazione che mi aiuti nella crescita del mio neonato, se la chiamo semplicemente “Neonato” utilizzo un nome alquanto generico, che sarebbe difficile da proteggere a livello legale e di trademark. In questi casi bisogna armarsi di un po’ di creatività e cercare di allargare il concept, lo stesso meccanismo spiegato per la creazione delle funzionalità della nostra applicazione. Possiamo anche giocare a livello di acronimi e collegamenti col mondo delle app, così la nostra idea potrebbe chiamarsi “iNeonato”, ma anche “Neonapp”, tutti nomi abbondantemente al di sotto dei 13 caratteri. Per cercare di distinguermi dalla massa di app presenti, o che verranno sviluppate in futuro che abbondano di iQualsiasicosa e Qualsiasicosapp, potrei pensare più al senso della nostra applicazione che in realtà è la prima app utilizzata dal neonato… Il nome potrebbe essere “MyFirstApp”: corto, essenziale e soprattutto internazionale.

Quando scegliamo il nome per la nostra app, dobbiamo ovviamente verificare che nessun altro abbia già utilizzato le parole che abbiamo individuato noi. Ricordiamoci di controllare su tutti gli app store ma anche in rete, accertiamoci insomma che non ci sia un altro software già sviluppato che si chiama come la nostra applicazione. Un ultimo controllo deve essere relativo alla potenziale presenza di marchi registrati su alcune parole usate: esistono diversi siti che offrono questo servizio gratuitamente: inserendo un nome di fantasia vengono restituiti nomi di prodotti e software eventualmente già registrati presso un ufficio marchi e brevetti internazionale: verificate chiaramente che non ci siano registrazioni sul nome da voi scelto.

Bisogna prestare molta attenzione e tenere in considerazione il copyright: stiamo molto attenti a non scegliere parole coperte da diritto d’autore, perché potremmo andare incontro a grossi problemi legali e la nostra applicazione potrebbe essere addirittura rimossa dagli store, magari proprio nel momento in cui stava cominciando a diffondersi, oppure in fase di successo.

Un esempio abbastanza recente[38] è costituito dalla parola “memory” utilizzata in moltissimi mini giochi all’interno dei negozi di app. La Raversburger®, azienda tedesca di giochi in scatola, ha ottenuto il copyright sulla parola “memory” per la classe dei giochi che identifica un famoso e diffuso gioco dell’azienda. Tutti gli sviluppatori di applicazioni il cui nome conteneva la parola “memory” sono stati invitati a modificarlo; in caso contrario, l’Apple App Store si sarebbe visto costretto a rimuovere l’applicazione, in quanto non conforme alle norme di utilizzo e in violazione del copyright della Raversburger.

Figura 4.37 – Il gioco Memory della Raversburger. L’azienda tedesca è riuscita a far valere il proprio marchio Memory nei confronti della categoria Giochi degli app store.

Il nome dell’applicazione può cambiare a seconda della lingua: la vostra app può quindi avere nomi differenti per mercati geografici e linguistici distinti. Vedremo in seguito come utilizzare questa possibilità per piccole app per un posizionamento più aggressivo all’interno degli store. Personalmente, nel caso di progetti importanti, quando si punta molto a una determinata applicazione in tanti mercati diversi, sconsiglio di cambiare il nome: pensiamo ai casi di successo precedenti, “Uccellini Arrabbiati” è meno accattivante e più lungo di Angry Birds, così come “Corsa del Tempio” è un po’ più generico e fa meno brand di Temple Run. La traduzione del nostro marchio genera una dispersione di energie su nomi diversi e una frammentazione della comunicazione che diventa molto complessa da gestire: nomi diversi in mercati differenti… Pensiamo anche solo al supporto sui canali social: diventerebbe molto costoso e complesso fin dall’inizio; credo che sia più opportuno creare, soprattutto nella prima fase, il maggior numero di economie di scala all’interno dei nostri sforzi nel marketing.

Quando scegliete un nome, infine, controllate immediatamente che i domini principali (.com in particolare se il progetto è internazionale) siano disponibili e registrateli subito. Fate la stessa cosa sui principali social network, anche se non volete fare un’attività su Pinterest o Instagram fin dall’inizio, che però potrebbe essere utile in seguito; vi consiglio di “bloccare” subito il nome della vostra app anche in questi canali sociali: registrate semplicemente i vari account.

Dopo il nome, la seconda importante caratteristica della presentazione della vostra applicazione è l’icona da associarvi, cioè il quadratino accanto al nome che rappresenta l’app, quello che vorreste fosse presente nella prima schermata di milioni di smartphone e tablet, sostanzialmente il logo di ogni applicazione. Ricordiamo che abbiamo un quadratino di circa un centimetro di lato nel quale esprimere e sviluppare tutta la nostra creatività. L’icona deve rappresentare graficamente la nostra applicazione. Deve essere quindi in grado da una parte di catturare l’attenzione in mezzo ai concorrenti nel momento della ricerca dell’utente e dall’altra essere gradevole e accattivante dal punto di vista estetico, da tenere sullo smartphone, magari anche in prima pagina, pronta a essere lanciata spesso!

In questo momento di sovraffollamento degli app store è fondamentale diversificare il proprio progetto rispetto a quanto fanno i competitor, in modo tale da essere ben riconoscibile nella lista delle applicazioni. Nel file .xls di analisi della concorrenza inserite anche queste note: alcune tipologie di applicazioni, per esempio quelle del meteo, tendono ad assomigliarsi molto l’un l’altra a livello di icona: stessi colori (blu), stessi tratti (icone), stessi elementi grafici (sole e nuvole). Alcuni soggetti hanno cominciato a differenziarsi anche come simbologia, sono nate icone totalmente nuove per questa categoria con colori adottati per spiccare all’interno di listati blu e grigi.

Figura 4.38 – Esempio di listato di una serie di app di meteo dell’Apple App Store, dove la maggior parte delle icone presenta colori di base simili, mentre le poche con colori unici staccano più dal listato e si differenziano meglio all’interno dei risultati.

Una buona regola è quella di individuare due o tre elementi grafici e fare tante prove, sovrapponendo e sostituendo un’icona a caso del listato dei risultati con le vostre e provando a vedere direttamente quanto il logo della vostra app sia visibile nei listati.

Fate le stesse prove anche sullo smartphone e/o sul tablet per rendervi conto dell’effetto che ottiene l’icona direttamente sul dispositivo dell’utente: spicca tra le altre? È gradevole esteticamente? Ricorda il mio marchio e il nome dell’applicazione? Se guardiamo agli esempi di grandi applicazioni e di brand importanti, ma nati solo sul digitale, che vogliono “imporre” il proprio marchio come quelle dei social network, per esempio, vediamo come l’elemento grafico sia sempre solo uno: la “F” di Facebook, l’uccellino di Twitter, la “P” di Pinterest, e la G+ di Google Plus.

Provate a mettere le icone di test direttamente sullo smartphone o sul tablet per vedere l’effetto che fa sul dispositivo mobile.

Per coloro che ancora oggi vogliono sviluppare versioni a pagamento e gratuite distinte, senza utilizzare i vantaggi dell’in-app purchase, esiste un problema abbastanza frequente: la diversificazione dell’icona della versione lite, quella gratuita, e della versione pro a pagamento. Per non occupare spazio alla grafica o caratteri al nome, comunemente si ricorre all’utilizzo di una fascetta sull’angolo in alto a destra per diversificare la versione free.

Figura 4.39 – Un esempio grafico e di differenziazione delle icone di una versione free e della versione a pagamento della stessa applicazione: Angry Birds.

Questa scelta grafica è divenuta ormai quasi una consuetudine: gli utenti riconoscono immediatamente il concetto di una versione limitata dell’app; l’utilizzo della fascetta per la versione gratuita quindi può essere adottata da tutti gli sviluppatori senza porsi tanti problemi e per evitare di sprecare risorse ed energie inutilmente.

So.Lo.Mo.

L’acronimo So.Lo.Mo. racchiude in sé tre concetti fondamentali: Social, Local e Mobile, le tre componenti imprescindibili per una soddisfacente esperienza dell’utente digitale moderno. Per comprendere l’importanza di questi tre fattori, dobbiamo osservare gli sviluppi che hanno portato gli utenti a richiedere che i brand includessero aspetti social, locali e mobili all’interno della loro comunicazione.

I computer desktop, ma anche i notebook, hanno il limite di non riuscire a unire nell’immediatezza l’esperienza online e la conversione[39] fisica dell’utente. Negli ultimi 3-5 anni gli smartphone hanno implementato funzionalità tipiche del computer, basti pensare che aziende come Apple e Google si sono buttate nel mercato degli smartphone per garantire una personalizzazione nell’esperienza in mobilità dell’utente, fornendo applicazioni. In sostanza, lo smartphone ha il grande vantaggio di aver liberato le persone dai confini dei muri casalinghi o dell’ufficio, permettendo loro di avere accesso alle informazioni online 24 ore su 24, 7 giorni su 7, da qualsiasi luogo dove ci sia copertura di campo!

La grande diffusione degli smartphone che, come già detto, hanno integrato funzionalità quali browser e GPS, ha permesso lo sviluppo dell’effetto So.Lo.Mo.

Il concetto del So.Lo.Mo può essere spiegato con un’espressione matematica: è il risultato della vita reale per Internet per tempo reale.

Figura 4.40 – La formula matematica dell’effetto So.Lo.Mo.

Infatti è proprio così: la trasposizione della propria vita su canali sociali in tempo reale e in ogni luogo. Per l’azienda, avere un approccio So.Lo.Mo. significa fornire un engagement considerevole con il brand: contemporaneamente, nel mondo digitale e in quello reale, indipendentemente dal canale con cui l’utente si mette in comunicazione con l’azienda, sia esso una mail, il sito, un QR code sulla confezione del prodotto, il contatto in negozio, la pagina Facebook o l’applicazione mobile.

L’azienda deve rendersi conto che l’interazione con l’utente non è più soggetta a confini fisici e costretta tra le mura domestiche o di un ufficio, ma è in tempo reale, sulla sfera digitale, avendo una localizzazione fisica ben precisa e con persone fisiche. La comunicazione moderna tra aziende e persone avviene mentre il vostro cliente è davanti al vostro prodotto: pensate alle persone che inviano su Facebook le foto di abbigliamento chiedendo ad amici e amiche quale capo comprare[40]. La relazione moderna avviene mentre l’utente sta godendo e usufruendo del vostro servizio: pensiamo ai tweet[41] quasi quotidiani inviati dai passeggeri a Trenitalia mentre aspettano o sono su treni in ritardo, ma anche ai commenti su Facebook e alle recensioni su TripAdvisor di un hotel mentre l’ospite sta ancora alloggiando in quella struttura.

I consumatori vogliono brand sempre più sociali, con funzionalità locali e declinati anche sui dispositivi mobili. Le motivazioni di queste necessità sono da cercare nell’evoluzione tecnologica, che permette agli utenti maggiori libertà senza barriere di tipo spaziale e nella mutazione delle necessità di consumo. Il bisogno e il desiderio di socialità tipici dell’essere umano (cfr. piramide di Maslow[42]) sono stati soddisfatti dai social network, che offrono la possibilità di condividere i propri pensieri, le proprie attività, quello che sosteniamo e via dicendo: i messaggi su Facebook o su Twitter spaziano dallo sport alla politica, dalle vacanze di amici e conoscenti alle rivoluzioni di studenti che si organizzano e si incontrano sui social network. Pensare che il mondo digitale sia qualcosa di a sé stante, completamente scollegato dalla realtà, è un grandissimo errore. Ciò che avviene sui social network è molto più concreto e collegato al mondo di quanto si possa immaginare: guardando le attività sociali degli utenti e dei cittadini di una nazione, si può comprendere meglio che cosa sta succedendo o addirittura che cosa sta per succedere. Fenomeni come il Movimento Cinque Stelle, ma anche le rivoluzioni islamiche del Nord Africa del 2013, sono degli esempi emblematici di come social e smartphone stiano rivoluzionando il mondo reale e sistemi consolidati da decine di anni, che traballano a colpi di tweet e di retweet.

I sistemi di geolocalizzazione rispondono inizialmente a un bisogno di orientamento, sono quindi assimilabili alla funzione di un GPS; successivamente, però, è stata integrata anche la possibilità di visualizzare i punti di interesse e gli esercizi commerciali vicino alla posizione rilevata. Queste informazioni possono essere sfruttate in modo nuovo e attivo da parte dell’esercente commerciale, mentre l’utente le sta utilizzando passivamente. Un esempio è dato quando, nell’estate del 2013, Algida, per promuovere il cornetto per la stagione, ha stretto un accordo con l’applicazione Waze[43]: chiunque utilizzava quel navigatore satellitare vedeva tutti gli esercizi commerciali dove era in vendita il cornetto: bar, ristoranti, pizzerie… A livello di marketing, una mossa molto intelligente da parte di Algida: riuscire a fare quello che in termini di marketing viene definito come “brand awarness” a basso costo su milioni di utenti, promuovendo contemporaneamente centinaia di migliaia di distributori e punti vendita dei propri prodotti; e tutto ciò mentre l’audience era passiva e stava pensando ad altro (raggiungere la propria meta); ma la voglia di un gelato può arrivare in qualsiasi momento… (Figura 4.41).

Figura 4.41 – Esempio di brand awarness sull’app navigatore satellitare Waze da parte di Algida.

L’utente che utilizza un sistema di navigazione mobile non ottiene più solo informazioni stradali che deve seguire per raggiungere la sua destinazione; piuttosto viene a conoscenza, attraverso un’app digitale, del mondo analogico circostante che sta attraversando. Le attività commerciali esistenti vicino alla sua posizione, le località di interesse storico, i monumenti, le spiagge, i sentieri: il So.Lo.Mo. è ovunque.

I social network si basano e utilizzano sempre di più le funzioni di geolocalizzazione: il complesso di interazioni che l’utente può cercare è molto più ampio. Pensiamo solo al social network Foursquare che, per esempio, oltre alla possibilità di fare check-in, parzialmente superata, affianca la possibilità di lasciare commenti circa l’efficienza di un dato negozio, permettendo al gestore di offrire promozioni a fronte di definite azioni sul social e via dicendo (Figura 4.42).

Figura 4.42 – L’app di Foursquare in azione.

La funzionalità di geolocalizzazione diventa motivo di socializzazione. “Fammi vedere dove sono i miei amici”, “Fammi vedere se c’è qualcuno dei miei contatti vicino alla posizione in cui mi rileva il GPS”: queste richieste racchiudono in sé la necessità di socializzare e sono diffusissime soprattutto tra le nuove generazioni.

La geolocalizzazione è già stata ampiamente integrata tra le funzionalità tipiche dei social network per rispondere all’esigenza dell’utenza di sapere dove ci si trova. Foursquare, per esempio, è nato proprio con questa destinazione: la geolocalizzazione degli utenti. Tale funzionalità è stata poi integrata anche da Facebook con places e da Twitter e Instagram. La necessità dell’utente non è solamente quella di comunicare la propria posizione ma anche quella di cercare amici vicino a sé oppure attività commerciali coerenti con i propri interessi.

Smartphone non dumbphone: sfruttare la sensoristica di bordo

I telefonini moderni sono smart: intelligenti, svegli, veloci, pieni di una serie di sensori e funzionalità cosiddette “built-in”, ovvero perfettamente integrate all’interno del dispositivo. Se pensiamo a livello dimensionale di spazio e anche a livello di costo a tutta la sensoristica presente all’interno di uno smartphone, e la paragoniamo alla stessa tecnologia di soli dieci anni fa, possiamo comprendere i progressi tecnologici in termini di miniaturizzazione e di riduzione dei costi. Uno smartphone attualmente è dotato di:

Schermo Touch: un display, più o meno ampio, col quale interagisco direttamente con l’hardware attraverso le mie dita senza l’ausilio di un controller come il mouse, il joystick o il trackpad.

Accelerometro e sensore giroscopico: una delle innovazioni maggiori degli smartphone è stata l’introduzione all’interno del dispositivo dell’accelerometro collegato a un sensore giroscopico, che permette di calcolare esattamente l’orientamento del dispositivo e di misurare le vibrazioni e i movimenti dello stesso. Questa sensoristica permette infnite applicazioni: dai giochi alle mappe, dai sistemi di controllo del movimento alla bolla da falegname per controllare se appendere la vostra mensola perfettamente orizzontale.

Orologio e cronometro: ogni smartphone ha al suo interno un orologio, che può aggiornarsi automaticamente collegandosi alle celle telefoniche, così come tutti gli accessori a esso collegati: cronometro, conto alla rovescia, sveglia ecc.

wi-fi e 3/4G: possibilità di accedere alla rete attraverso i network degli operatori mobili (cosiddetti 3G e 4G/LTE) e di connettersi a una qualsiasi rete wi-fi pubblica o privata.

Registratore e riproduttore audio: ogni smartphone è in grado di registrare suoni e voci in modo professionale e di riprodurre fle audio di diversi formati in modo perfetto. Il successo dell’iPhone è in qualche modo legato al mondo della musica e audio attraverso l’iPod e iTunes.

Fotocamera digitale: capace di scattare immagini a svariati mega pixel, dotata di zoom digitale e fltri precostruiti o attraverso applicazioni.

Videocamera digitale: uno smartphone registra video in alta risoluzione, possiede stabilizzatori di immagini e una registrazione con un elevato frame rate.

Scanner: l’ottica del telefono permette di scansionare testi, immagini, ma soprattutto codici a barre e QR Code. Le applicazioni delle scansioni sono quindi infnite, sia in ottica B2B (nuovi modi di gestire piccoli e grandi magazzini), sia B2C: pensiamo a tutte le app di gestione della spesa del supermercato con lettore di codici a barre integrato.

Memoria digitale: gigabyte di spazio a disposizione per salvare tutto.

GPS: ogni telefono è dotato di GPS integrato, sempre più preciso e accurato.

Bussola: strumento di orientamento utilizzato da moltissime app di utilizzo all’aria aperta, fondamentale per non perdersi nella giungla.

NFC (Near Field Communication) e RFID (Radio Frequency Identifcator): un sensore di ultima generazione che permette la comunicazione via radio frequenza a distanza ravvicinata. Questo sensore ha dei risvolti rivoluzionari in quanto permette la comunicazione del dispositivo mobile con un altro hardware semplicemente avvicinandolo all’oggetto con il quale deve interagire. Gli smartphone, attraverso l’NFC, diventano dei bancomat e delle carte di credito, delle chiavi di hotel o per un check-in all’aeroporto. Questa tecnologia permette anche di attivare gli RFID e di interagire con essi, collegando il dispositivo a oggetti fsici e creando una vera e propria rete peer-to-peer tra dispositivi o dispositivo e RFID. Siamo solo all’alba dello sviluppo di svariate applicazioni che sfrutteranno questi sensori all’interno dei dispositivi mobili.

Dispositivi hardware di terze parti: attraverso le prese di ingresso delle cuffe e dell’alimentazione è possibile collegare e sincronizzare il proprio smartphone con dispositivi hardware di terze parti, per esempio braccialetti come quello di Jawbone, bilance elettroniche, termometri digitali, misuratori di pressione e centinaia di dispositivi in fase di realizzazione. Siamo solo all’inizio di questa rivoluzione: gli ultimi modelli smartphone della Samsung sono già dotati di un pacchetto di sensori predisposti a interagire con dispositivi di terze parti in ambito medico col pacchetto Samsung Health. Anche in questo caso siamo solo all’inizio dello sviluppo del vero e proprio “Internet of things” e di tutte le rivoluzionarie applicazioni e oggetti indossabili e sensori esterni che attaccheremo ovunque per misurare e controllare a distanza con il tablet o lo smartphone l’oggetto (l’animale o la persona).

Pensiamo a tutti questi sensori separatamente e a ogni oggetto digitale specifico di quella funzione: dal GPS per l’automobile alla fotocamera digitale, da un registratore audio a una videocamera; visualizziamo tutti questi oggetti insieme e calcoliamo il costo totale dei vari gadget digitali: in questo modo possiamo comprendere facilmente la potenza che abbiamo a disposizione ogni giorno e il prezzo relativamente ridotto di tutta questa tecnologia. Dal punto di vista di uno sviluppatore di app, è fondamentale avere sempre presente queste funzionalità: gli utenti comprano cellulari moderni e utilizzando quotidianamente queste funzioni, scattano foto, registrano voci, aprono mappe, si connettono. Hanno pagato centinaia di euro il loro smartphone e provano soddisfazione nel vedere le sue funzionalità all’opera: tra i primi giochi di successo su iOS segnaliamo tutta la serie di “labirinti a pallina”, emulatori di vecchi giochi in legno dove, attraverso l’equilibrio del tavolo da gioco, si dovevano evitare buche e ostacoli e raggiungere la fine del percorso. La novità dell’accelerometro ha portato alla trasposizione di questo splendido gioco antico sui moderni dispositivi mobili: tenere in equilibrio il proprio smartphone per evitare le buche è stato uno dei passatempi preferiti di milioni di neoutilizzatori dei primi iPhone, compreso l’autore. Quando sviluppate la vostra idea, cercate di sfruttare al massimo tutta la sensoristica di bordo, salvaguardando al contempo il livello di batteria del dispositivo. Provate a collegare il mondo analogico con quello digitale, sfruttando alcuni dei sensori di bordo: il GPS e la fotocamera in primo luogo. Concentratevi sulle funzionalità che potrebbero essere utili alla vostra app, spingetele al massimo, siate creativi innovando il più possibile.

Caso studio: Condom08

Un esempio fantastico di come sia possibile l’utilizzo di tutte queste funzionalità e di questi sensori in modo intelligente e dell’effetto So.Lo.Mo. è dato dalla municipalità di Stoccolma, all’interno di un progetto per la sensibilizzazione all’utilizzo dei preservativi da parte dei giovani per diminuire i rischi di malattie sessualmente trasmissibili, AIDS in primis.

Figura 4.43 – L’app di Condom08.

Figura 4.44 – Il sito Internet creato per l’iniziativa Condom08.

La pubblica amministrazione della capitale svedese ha ideato un progetto, il cosiddetto Condom08[44], che si basava essenzialmente su un’app e un sito web: durante i numerosi concerti estivi di Stoccolma venivano distribuiti all’ingresso agli spettatori dei preservativi in omaggio. Sopra al packaging di ogni profilattico erano presenti una breve descrizione con tutte le indicazioni per diminuire i rischi di malattie sessualmente trasmissibili, ma soprattutto la spiegazione per il download di un’app per misurare la propria prestazione sessuale: bastava scansionare il QR Code presente sulla confezione per collegarsi e scaricare direttamente l’applicazione. Una volta installata, quest’app sostanzialmente attiva i vari sensori del telefono proprio durante la prestazione sessuale, dopo avere lasciato 10 secondi di attesa per potere “indossare” il preservativo (finalità principale del progetto), dopodiché si avvia il cronometro integrato per la misurazione della durata, il registratore audio per quella dei decibel emessi, il GPS per la posizione e la localizzazione a fini statistici, l’accelerometro e l’oscillometro per comprendere il livello di vibrazione e dinamica della prestazione stessa.

Figura 4.45 – L’app di Condom08 in azione.

Il tutto con un approccio giovane e pensato per i giovani. Una volta registrata la prestazione era possibile iscriversi al sito Internet del progetto, selezionare un profilo (età, altezza, peso, colore dei capelli, ecc.) e caricare i propri dati online, chiaramente anche in forma anonima o sotto forma di nickname. In questo modo era possibile confrontarla con quella di altri profili e la media generata dagli utenti. L’app è impazzata tra i giovani svedesi (e non solo), la municipalità ha usato i dati ricevuti in modo aggregato sia per avere dei dati molto interessanti per svolgere ulteriori ricerche, sia creando statistiche a sfondo umoristico e promuovendo il fenomeno in tal senso sia in ambito digitale, sia con delle tradizionali affissioni pubbliche cartacee: cartelloni con frasi come “In questo quartiere hanno consumato 40 persone nell’ultimo weekend”, “Le ragazze more che hanno un cane fanno più rumore delle bionde proprietarie di gatti”, e così via.

Figura 4.46 – La cartellonistica stradale e i banner di Condom08.

Il progetto ha subito ottenuto un grande successo, migliaia di post su Facebook e tweet hanno creato un effetto virale tra gli utenti, si è parlato della problematica su diversi livelli, a volte leggeri, a volte in modo più serioso, ma se ne è parlato, obiettivo fondamentale di tutto il progetto; il messaggio è arrivato in modo pervasivo a tutti i giovani di Stoccolma, un risultato impensabile prima dell’avvento dei dispositivi mobili. La creatività e l’innovazione hanno giocato un ruolo chiave in tutto il progetto: hanno creato un nuovo modo di comunicare un problema purtroppo presente da molti anni in una maniera nuova e interattiva, proprio ciò che i giovani e le nuove generazioni vogliono, un sistema perfetto per catturare l’attenzione dei nativi digitali, molto più efficace di qualsiasi campagna televisiva da milioni di euro. Costi ridottissimi, interazione dell’audience e una mole di dati scientifici sui quali lavorare anche a livello di municipalità.

I risultati sono stati notevoli:

Migliaia di interazioni sociali sull’argomento: i giovani parlavano online del fenomeno tra di loro, aumentando la propria consapevolezza e facendo conoscere il progetto ad altri coetanei.

Oltre 5.900 prestazioni registrate e inviate dagli utenti sul portale in pochissimo tempo per un totale di 139 ore e 15 minuti di durata e un livello medio di rumore pari a 54 decibel.

L’obiettivo iniziale era di 1.000 risultati registrati, che è stato quindi ampiamente superato.

Le interviste post progetto hanno evidenziato, oltre al fatto che praticamente tutti i giovani di Stoccolma ne avevano perlomeno sentito parlare, che il 39% dei giovani intervistati erano adesso più positivi e propensi all’utilizzo del preservativo rispetto a prima: obiettivo che ha superato del 98% le attese del progetto.

27. Il dato si riferisce solo ad app sviluppate per iOS.

28. Un esempio è il caso studio Wordz vs Ruzzle presentato in seguito nel libro.

29. Il termine inbound marketing indica una modalità di marketing centrata sull’essere trovati da potenziali clienti (outside-in) in contrasto con la modalità tradizionale, detta anche outbound marketing (inside-out) che è imperniata su un messaggio direzionato unicamente verso il cliente. Fonte: Wikipedia Italia.

30. Un esempio è il caso studio Wordz vs Ruzzle presentato in seguito in questo libro.

31. Questi dettagli possono essere visualizzati sempre; il sottoscritto, quando vuole fare lo sbruffone con suo fratello, altrettanto appassionato di sci, gli mostra questa schermata che rimane tuttora uno dei record di famiglia migliori: oltre 100 km in un giorno con gli sci non è male.

32. Per chi non ha esperienza come genitore: le curve di crescita e di peso del neonato sono per molte giovani coppie una vera e propria ossessione.

33. La posizione dell’autore, parlando soprattutto da padre, è alquanto critica al riguardo, ma sono favorevole alla libertà personale ed evito commenti ulteriori al riguardo.

34. Shazam: è stata una delle primissime app sviluppate e ha raggiunto un successo enorme; installata e utilizzata da milioni di utenti, questa applicazione riesce a riconoscere i brani musicali semplicemente ascoltandoli. Vi piace una canzone che ascoltate in un bar o in un locale (non dal vivo) e volete sapere chi la canta? Basta lanciare l’app di Shazam, metterla in ascolto e dopo alcuni istanti si sa esattamente il nome della canzone, del cantante o del gruppo e dell’album in cui è stata pubblicata.

35. Ruzzle: sviluppata da MAG Interactive, ha raggiunto i 50 milioni di giocatori. Avete 2 minuti per trovare quante più parole possibili combinando le lettere adiacenti che compongono il quadro-puzzle. Un rompicapo che tiene allenata la mente e in cui si può sfdare un amico o un avversario casuale.

36. Angry Birds: sviluppato e pubblicato dall’azienda fnlandese Rovio Mobile, è un’app divisa in più episodi. Da una parte gli uccellini arrabbiati e dall’altra i maiali da sconfggere, rei di aver sottratto le uova dei primi. Con la fonda si deve cercare di distruggere i maialini e tutti gli ostacoli. Ogni specie di uccello ha peculiarità differenti. Ci sono: Red, Blues, Chuch, Bomb, Matilda, Terence, Stella, Hal e Mighty Eagle.

37. Temple Run: sviluppato dalla casa produttrice Imangi Studios, è un gioco d’azione in cui vi è un esploratore in fuga da un branco di scimmie, poiché ha rubato un idolo da un tempio. Il giocatore deve evitare tutti gli ostacoli che incontrerà in ogni schema. Gli schemi sono infniti!

38. Novembre 2012 (http://www.tuaw.com/2012/11/15/apple-banning-games-with-memory-in-the-name-from-app-store/).

39. Per conversione qui si intende il completamento dell’obiettivo prefssato nella strategia. Può essere il check-in nel locale, può essere la geolocalizzazione dello status sul social network e altro ancora.

40. La moda e la tendenza del social shopping sono un fenomeno molto sottovalutato dalle stesse case di moda.

41. I messaggi degli utenti su Twitter, i loro cinguettii.

42. Realizzazione di bisogno di appartenenza e realizzazione di se stessi.

43. Waze: si tratta di un’app di navigazione stradale sociale, sviluppata da una start-up israeliana e acquistata da Google nel 2013. Si differenzia dai competitor perché aggiornata dagli utilizzatori che possono segnalare particolari avvenimenti sul percorso (code, traffco, autovelox, incidenti ecc.) in tempo reale.

44. Condom08: splendido video di presentazione del progetto e dei suoi risultati http://www.youtube.com/watch?v=IHo57GOqKTY.

CAPITOLO 5

LA CREAZIONE DELLA BETA APP

Le scelte: team di sviluppo, piattaforme, SO, tecnologia

Spesso chi ha un’idea per sviluppare un’applicazione non è una persona con competenze tecniche specifiche. Le app vengono sviluppate da aziende specializzate per imprese terze che commissionano un lavoro. È importante, quindi, avere una conoscenza generale degli aspetti tecnici, pur non essendo esperti in quel settore, sia per capire esattamente che cosa sia possibile fare e che cosa non sia fattibile, sia per spiegare esattamente come vorremmo che si sviluppasse la nostra idea. Possiamo dividere le figure professionali necessarie alla realizzazione di un progetto serio di sviluppo e lancio di un’applicazione in due gruppi: il gruppo degli sviluppatori e il gruppo a supporto dell’app. Alcune delle figure professionali possono ricoprire, per competenze tecniche ed esperienza, più ruoli all’interno del progetto. Diffidate di quelli che affermano che possono sviluppare tutto da soli o con solo due persone, perché è una sfida praticamente impossibile; per quanto un tecnico sia bravo ed eclettico, difficilmente potrà possedere tutte le competenze necessarie per seguire adeguatamente il progetto e per rimanere aggiornato su tutti i fronti di sviluppo del mercato. Il mondo delle app è in continua e fortissima evoluzione sotto tutti i punti di vista: interfacce, programmazione, integrazione con sensoristica e sistemi operativi mobili sempre in aggiornamento, marketing delle app a 360 gradi e supporto al lancio del progetto; tutte queste attività necessitano di una forte specializzazione e di un aggiornamento costante e continuo: ci vorrebbero diverse vite parallele per poter essere dei professionisti in tutti questi settori.

Ritornando alla composizione della squadra: il gruppo degli sviluppatori è composto essenzialmente da tre distinte aree di figure professionali e dalle relative attività principali (vedi la Tabella 5.1).

Gruppo degli sviluppatori | |
Grafici | Programmatori | Ideatore ed esperti di digitale

• Creano i layout delle schede.

• Sviluppano le interfacce migliori.

• Realizzano menu e icone personalizzate.

• Adattano i layout alle diverse dimensioni e risoluzioni degli schermi dei dispositivi.

• Disegnano gli elementi decorativi necessari e li digitalizzano.

• Eseguono test di usabilità.

• Sviluppano il codice e la programmazione del software per i differenti sistemi operativi.

• Implementano l’app con le funzionalità dello smartphone.

• Integrano il software con la sensoristica di bordo del dispositivo mobile in modo efficiente.

• Collegano a eventuali database e inseriscono funzionalità integrate coi social network.

• Implementano l’App Analytics.

• Eseguono i crash test.

• Sviluppano lo schema dell’app e ne organizzano i contenuti e le funzionalità.

• Stabiliscono lo schema di navigazione.

• Analizzano la concorrenza.

• Includono tecniche di marketing virale, social e/o tradizionale all’interno dell’app.

• Redigono il piano di comunicazione e di marketing distribuendo il budget a disposizione.

• Stabiliscono le codifiche dell’App Analytics.

• Coordinano tutto il gruppo di lavoro.

Tabella 5.1 – Il gruppo degli sviluppatori: distinzione nelle tre aree principali e descrizione delle attività di ogni area.

Il gruppo degli sviluppatori dovrebbe avere un minimo di tre figure professionali distinte per le relative aree di attività:

Grafci: laureati presso un’accademia di Belle Arti, in disegno industriale, in design, ma anche talentuosi autodidatti con tanta passione ed esperienza. Questi tecnici devono disegnare tutta l’applicazione: dal logo a ogni singola interfaccia ed elemento grafco presente all’interno dell’app. Paragonando lo sviluppo di un’app alla produzione di un’automobile, i grafci costruiscono la carrozzeria, stabiliscono l’aerodinamica e disegnano gli interni della vostra “automobile” in ogni minimo dettaglio: dal paraurti allo specchietto retrovisore, dalla maniglia della portiera al simbolo dell’indicatore del carburante. Per alcune tipologie di applicazioni, come i giochi o i libri interattivi, quest’area di lavoro potrebbe essere composta da decine di persone. Tutti i menu e le icone devono essere creati e posizionati all’interno dei nostri layout grafci. A differenza del web, per le app l’ottimizzazione degli spazi, la raggiungibilità delle funzionalità e l’usabilità dell’applicazione, in primo luogo la semplicità nell’utilizzo del touchscreen, sono essenziali e fondamentali e possono decretare il successo o l’insuccesso di un progetto. Per questo motivo i grafci devono testare l’applicazione in termini di usabilità e semplicità di utilizzo in modo molto approfondito e almeno per qualche giorno: solo provando personalmente il software che create potrete essere certi del valore di ciò che state sviluppando. Per ottimizzare le interfacce i grafci devono ottenere due informazioni fondamentali dall’area degli ideatori ed esperti di digitale: innanzitutto devono comprendere se esiste un’audience specifca di utilizzatori: donne, medici, studenti, camionisti, architetti, pensionati, chiunque ecc. In secondo luogo devono conoscere quali siano i contesti tipici di utilizzo dell’applicazione: mentre guido, quando cammino, in vacanza, la sera, nei weekend ecc. Queste due informazioni sono essenziali per sviluppare adeguatamente interfacce e funzionalità: se sto sviluppando un’applicazione per donne, la scelta dei colori delle schede dell’applicazione dovrà essere studiata in tal senso, così come un’app che funzioni mentre sono alla guida deve tenere banalmente in considerazione l’orario per capire se usare la modalità “notturna” per non accecare o infastidire il guidatore. I grafci hanno quindi bisogno di queste indicazioni fn dall’inizio. Nel caso in cui un’app sia per chiunque e utilizzabile in qualunque contesto (un indicatore iniziale di un’app di poco successo) allora i grafci dovrebbero installare l’app anche sullo smartphone del nonno e della nonna (ma anche papà e mamma potrebbero essere suffcienti) e vedere come utilizzano la vostra applicazione: quanto tempo impiegano a navigare all’interno dell’app, se trovano tutte le funzionalità a disposizione e quali utilizzano di più. I nonni e i genitori sono i vostri migliori beta-tester: nel caso in cui la vostra idea si rivolga anche a loro, se ce la fa il nonno ce la fa chiunque!

Programmatori: laureati in ingegneria, in informatica oppure, anche in questo caso, autodidatti, ma che abbiano seguito almeno qualche corso specifco di un certo livello. Riprendendo il parallelo automobilistico, i programmatori progettano e realizzano tutto il motore, l’impianto elettrico e la meccanica; prendono in considerazione le varianti di motore che dovrà essere montato e regolano ogni singola vite e bullone di tutta la vettura. I programmatori sono fondamentali per non restare a piedi! Potete avere l’idea più bella del mondo, la grafca e le interfacce da fare invidiare Apple e Google, ma se la vostra app si blocca una volta ogni cinque che viene utilizzata, oppure consuma il 10% di batteria in cinque minuti, allora il vostro progetto è morto in partenza. I programmatori dovrebbero essere esperti, viste le attuali condizioni di mercato, in tre ambienti di sviluppo: iOS, col relativo linguaggio di programmazione Object-C, Android, con la programmazione in linguaggio Java e Windows, con ambiente di sviluppo .NET. Per ottimizzare i costi e il budget iniziale e prima di pensare in grande, è un’ottima scelta quella di puntare allo sviluppo nativo per una sola piattaforma e decidere magari solo in un secondo momento e solo in caso di buoni riscontri dal mercato di sviluppare versioni native per altre piattaforme. Alternativamente, è possibile sviluppare l’app per un solo sistema operativo e utilizzare poi dei software che creino in modo automatico e semi-automatico (per le app più complesse) la versione per altre piattaforme: non avrete la versione nativa per Android ma, per molte applicazioni semplici, può essere un processo automatico e non dovrebbero esserci differenze sostanziali tra le versioni. Infne i programmatori potrebbero scegliere delle piattaforme (i cosiddetti framework), spesso disponibili in ambiente open source, che sono ambienti di sviluppo con molte librerie già a disposizione, dove concentrare tutte le energie di programmazione. In questo caso il framework offrirà tutti gli strumenti necessari per adattare la vostra app iniziale ai diversi sistemi operativi e tipologie di dispositivi mobili, smartphone e tablet in primis. I programmatori devono trasformare quindi in codice tutte le funzionalità pensate e i layout sviluppati; devono conoscere molto bene l’integrazione con le funzionalità del dispositivo, come il calendario, l’orologio, la rubrica, nonché tutte le modalità di integrazione con la sensoristica di bordo (GPS, fotocamera e così via). Anche in questo caso è importante comprendere il contesto di utilizzo, soprattutto in relazione a due fattori: la batteria e la banda disponibile. Se l’idea è quella di fare il tracking della giornata di sci, devo usare molti sensori del dispositivo, ma lo devo fare in modo intelligente, perché la mia applicazione rimarrà accesa (o in background) per tante ore e non posso permettermi di consumare tutta la batteria del dispositivo che utilizza il mio software, altrimenti non lo userà nessuno: ottimizzare e preservare la batteria del dispositivo è essenziale. L’altro aspetto che i programmatori devono sapere fn dall’inizio è il contesto di connettività nel quale si troverà l’utilizzatore: se in mobilità reale, quindi probabilmente in 3G/4G, oppure in modo più statico e quindi collegandosi a un wi-fi. Un’app per la ricerca di ristoranti deve essere veloce e leggera, un’app per l’analisi tecnica di titoli azionari può permettersi anche maggiore pesantezza di contenuti. I programmatori devono anche avere indicazioni chiare circa l’implementazione di elementi social all’interno dell’app, come per esempio la possibilità di connettersi e registrarsi all’app con lo stesso account di Facebook, oppure di accedere al proprio account Twitter, ma anche al Game Center di Google e di Apple e così via. Queste funzionalità possono giocare un ruolo chiave nel successo dell’applicazione (si pensi a Ruzzle) e deve essere chiaro fn da principio che cosa devono integrare e in che modo lo devono fare, nonché le politiche di permessi delle diverse aree e funzionalità pensate per la nostra app. Questi tecnici devono anche saper inserire tecnicamente i codici dei sistemi di App Analytics all’interno dell’applicazione stessa, con le codifche ricevute dagli esperti digitali. Infne, i programmatori devono scongiurare in tutti i modi qualsiasi possibilità di crash dell’applicazione: eventuali bug trascurati possono uccidere un progetto se non vengono corretti immediatamente. Ricordiamoci che le modifche alle app all’interno degli store non sono istantanee: l’utente deve scaricare la versione aggiornata e fno a che non farà l’aggiornamento dell’app stessa utilizzerà ancora la versione precedente contenente il bug. Inoltre un’app, soprattutto se a pagamento, che non funziona genera, giustamente, un fortissimo malcontento da parte degli utenti che si trasforma in recensioni a una sola stella all’interno dello store: l’app resterà così macchiata per sempre di questo errore. Mi è già capitato in passato di lavorare su app con recensioni altissime (4/5 e 5/5), ma con un voto medio molto più basso (2,5/5 e 3/5) perché erano state rilasciate delle versioni che si bloccavano su alcuni dispositivi e utenti inferociti avevano dato voti bassissimi. Le app erano state corrette in pochi giorni, ma le recensioni non sono state modifcate dagli utenti, se non alcune, e i voti bassi sono rimasti; tutto ciò per due semplici sviste e modifche dell’ultimo minuto senza crash test eseguiti adeguatamente. Non permettete che la svista di un programmatore crei una zavorra perenne al vostro progetto; il mercato è già molto competitivo, non createvi dei problemi da soli!

Ideatore ed esperti di digitale: in questo gruppo va inserito colui che ha avuto l’idea per l’app e almeno un esperto in nuove tecnologie mobili, laureati in scienze economiche e sociali, ma anche umanistiche, nonché persone che si sono specializzate e con una formazione ad hoc verso il marketing digitale in genere. L’ideatore è normalmente chiunque abbia una forte conoscenza di un settore e abbia avuto l’intuizione di come soddisfare un bisogno che lui stesso conosce molto bene: in generale può essere chiunque. L’ideatore potrebbe essere anche colui il quale ha a disposizione un contenuto continuamente aggiornato e voglia sfruttare questo patrimonio editoriale anche verso gli utenti in mobilità. Per continuare il nostro parallelo automobilistico: l’ideatore è il pilota collaudatore della nostra vettura, gli esperti di digitale sono tutta l’organizzazione della casa automobilistica: dalla logistica alla ricerca degli sponsor, dalla vendita del merchandising alla creazione del redazionale sulla rivista specializzata, nonché tutta la gestione dei concessionari e dei distributori. L’ideatore e gli esperti di digitale organizzano tutti i contenuti e le funzionalità dell’applicazione e li ordinano per priorità; pensano agli schemi logici di navigazione all’interno della propria app e stabiliscono i livelli di importanza delle varie sezioni. Redigono l’analisi dei concorrenti e il piano di comunicazione e marketing e gestiscono l’allocazione del budget per le differenti attività programmate di supporto. Gli esperti digitali comprendono che cosa e come misurare l’utilizzo della propria app da parte degli utenti: stabiliscono quindi le codifche per l’App Analytics soprattutto in termini di gestione degli eventi e delle etichette da dare agli stessi. È possibile misurare qualsiasi cosa, fatelo! Infne, gli esperti digitali coordineranno tutto il gruppo degli sviluppatori tenendo allineati i soggetti interessati al progetto e monitorando lo stato di avanzamento dei lavori nei tempi di rilascio previsti in qualità di project manager.

Parallelamente al gruppo degli sviluppatori, dovete costituire fin dall’inizio quello a supporto dell’app, ovvero il team di persone che si occuperà di lanciare in modo adeguato il nostro progetto in tutti i settori digitali per ottenere il massimo delle possibilità di successo. Anche in questo caso possiamo riproporre tre aree di specializzazione; nei casi più fortunati molte delle risorse umane che abbiamo inserito nelle rispettive aree del gruppo degli sviluppatori possono ricoprire, magari con un livello di competenza inferiore, anche queste aree. Il gruppo a supporto dell’app deve sapere come sfruttare al massimo tutti i canali digitali a disposizione: non si occuperà solo degli app store e dei contenuti da inserire collegati all’applicazione, ma anche del sito web dedicato, delle pagine dei social network, delle campagne pay per clic e di quelle di display advertising; insomma, un gruppo di persone specializzate soprattutto in web marketing.

Gruppo a supporto dell’app | |
Grafici | programmatori | Esperti di web Marketing

• Disegnano il layout del sito dedicato all’app.

• Forniscono tutti gli elementi grafici necessari al supporto dell’app: screenshot, banner, video, demo ecc.

• Forniscono la grafica e le infografiche per la comunicazione sui social network e sul web.

• Creano tutto il codice del sito web.

• Sviluppano eventuali applicazioni per i social network.

• Inseriscono framework pubblicitari di terze parti all’interno dell’app ove richiesti.

• Implementano le Web Analytics necessarie in modo corretto.

• Stabiliscono le regole di ASO e di SEO on page e off page da seguire.

• Gestiscono i canali sociali dell’applicazione.

• Organizzano attività di CRM e supporto ai clienti.

• Stabiliscono le campagne pubblicitarie da attivare e le gestiscono.

• Misurano in modo continuativo i risultati e operano modifiche strategiche.

Tabella 5.2 – Il gruppo a supporto dell’app: distinzione nelle tre aree principali e descrizione delle attività di ogni area.

Il gruppo a supporto dell’app è di vitale importanza, non inferiore a quello che la sviluppa. Uno degli errori più comuni dei piccoli sviluppatori di applicazioni, o di chi commissiona lo sviluppo di un’app, è quello di sottovalutare e, a volte, di ignorare completamente la fase preparatoria e di supporto continuativo al nostro progetto. In moltissimi preventivi che ho esaminato anche come parte terza indipendente, il lavoro veniva quotato fino alla pubblicazione dell’app, dopodiché il committente veniva completamente abbandonato a se stesso nella fase più importante e critica del proprio progetto; questo perché molto spesso chi sviluppava e preparava quei preventivi non aveva all’interno alcun esperto di marketing di applicazioni e marketing digitale in generale. Non aprireste mai un’attività commerciale senza nemmeno considerare un’insegna, un cartello, dei volantini, un aperitivo di presentazione della vostra attività. Pensate allo stesso modo per il lancio della vostra app. Una volta presente negli store il lavoro non è finito, anzi…

Grafci: sono sostanzialmente dei grafci web, devono disegnare il layout di tutto il sito web o mini-sito di supporto al lancio e alla promozione continuativa dell’applicazione. Questi tecnici e creativi devono realizzare tutto il materiale grafco necessario al supporto del prodotto: dagli screenshot dell’app da inserire all’interno degli store ai banner classici per il web e a quelli sviluppati per dispositivi mobili, dagli sfondi per i social network che si intendono utilizzare ai video di presentazione del funzionamento dell’app (molto interessante soprattutto in Google Play) e a eventuali altri video demo da inserire sulle piattaforme video come Youtube. Prediligete grafci che sappiano comunicare attraverso l’utilizzo dell’infografca: un metodo di comunicazione digitale che può essere veicolato sia sul sito web del progetto sia sui canali sociali e che riscuote un ampio successo tra gli utenti, a dispetto di uno sforzo realizzativo molto limitato. Nel caso in cui il budget sia estremamente limitato, suggerisco l’implementazione di un sito web perlomeno sotto forma di blog dell’app, utilizzando piattaforme open source gratuite quali Wordpress o Joomla, o altre che già conoscete.

Programmatori web: questi tecnici, o chiunque sappia realizzare un sito web dinamico in modo professionale, trasformano in codice (CSS, Html e dinamico) la grafca del sito web o del mini-sito o, alternativamente, implementano la piattaforma open source selezionata, per esempio Wordpress o Joomla, mettendo a disposizione tutti gli strumenti necessari per l’aggiornamento dei contenuti. Nel caso di applicazioni con una spiccata componente social dovranno implementare le integrazioni dei social, sviluppando app ad hoc per gli stessi e/o plug-in specifci anche dal lato web, come Facebook Connect. Infne i programmatori si dovranno occupare di implementare framework particolari o codici Javascript specifci di piattaforme pubblicitarie e di tracking di terze parti per rendere possibile determinate campagne specifche delle app come le affliazioni, nonché offrire tutte le informazioni e i dati necessari alle piattaforme di web e App Analytics interne ed esterne all’applicazione stessa.

Esperti di web marketing: queste fgure professionali sono dedite alla ricerca continua di visibilità e di promozione dell’applicazione attraverso i canali digitali di ogni tipo. In primo luogo lavoreranno sui contenuti presenti all’interno degli app store, ragionando sempre in termini di ottimizzazione del posizionamento nel negozio, ovvero di Application Store Optimization (ASO). Queste fgure professionali gestiranno tutti i contenuti e la comunicazione in ambito digitale: dalle pagine del sito web agli articoli sui canali sociali, dalle risposte agli utenti al monitoraggio e all’analisi continuativa delle loro recensioni, siano esse negli store, sui social, su siti web specializzati o direttamente via mail. Gli esperti di web marketing stabiliscono le campagne pubblicitarie digitali di qualsiasi genere: dagli annunci testuali di Google Adwords alle campagne banner direttamente sui dispositivi mobili e sul web, dai post e i tweet promossi a pagamento agli accordi di affliazione di app scontate e gratuite e quelli di scambio banner nelle app. Infne, questi professionisti devono analizzare e interpretare tutti i dati a disposizione di Analytics, per capire al massimo le tipologie e modalità di utilizzo della propria app da parte degli utenti e per comprendere le dinamiche di installazione dell’app stessa. L’analisi, l’interpretazione e la misurazione continuativa sono di fondamentale importanza per adottare modifche più o meno ampie, per migliorare sempre di più il proprio prodotto nonché per comprendere esattamente quali siano le modalità migliori di promozione della propria applicazione.

Cose da sapere… anche se non sei un grafico

Il design, le interfacce, l’estetica e l’usabilità sono armi importanti per battere la concorrenza, soprattutto se sviluppate app in settori molto competitivi. Un’estetica curata e in linea con l’audience della vostra applicazione è un elemento vincente, tanto quanto le funzionalità stesse della vostra app, e non deve essere sottovalutata. Anche la parte grafica deve essere approcciata con molta strategia.

Un errore comune è di cominciare immediatamente lo sviluppo del codice dell’applicazione e delle sue interfacce; il mio consiglio è di lavorare prima su carta, o comunque con un software di grafica standard come Photoshop, per creare una vera e propria demo prototipo delle interfacce. È fondamentale schematizzare tutte le funzionalità e la navigazione dei contenuti della vostra applicazione, dopodiché procedere con la creazione di un prototipo da utilizzare anche come demo. Creare e disegnare delle interfacce anche solo provvisorie prima di procedere con la realizzazione dell’applicazione vera e propria offre dei vantaggi notevoli che non devono essere trascurati.

Esistono decine di siti web[45] che offrono gratuitamente tutto il materiale cartaceo per permettere di schematizzare le interfacce direttamente su carta, utilizzando degli schemi precostruiti di elementi: potete quindi scaricare decine di PDF che, una volta stampati su carta, vi offrono la possibilità di vedere in dimensione reale come disegnare le interfacce. Sono estremamente utili in una fase iniziale di concept, perché possono essere usati anche da non grafici e quindi dall’ideatore e dagli esperti di applicazioni per creare le prime bozze senza costi del gruppo di grafica.

Figura 5.1 – Esempio di sketches per lo smartphone Samsung Galaxy 3.

In primo luogo, potete visualizzare lo schema della vostra app con poco dispendio di energie e di tempo; in questo modo potrete vedere quasi “in azione” la vostra idea e molto probabilmente apporterete delle piccole o medie modifiche proprio analizzando come utilizzare le interfacce e accedere alle funzionalità che avete solo immaginato e schematizzato: visualizzate la vostra idea! La modellerete molto meglio.

Un altro vantaggio enorme per la creazione di una demo su carta e in seguito una demo di interfacce è la condivisione dell’esperienza lato utente dell’app attraverso tutto il gruppo di lavoro: chiunque è un potenziale utilizzatore della nostra applicazione e molto probabilmente possiede uno smartphone (diffiderei un po’ di un esperto di interfacce, ma anche di un programmatore di applicazioni, che non possiedono nemmeno un dispositivo mobile). Tutto il gruppo di lavoro può suggerire modifiche e funzionalità in quanto utente: dovete pensare e immedesimarvi il più possibile come se foste utenti e non sviluppatori in questa fase. Visualizzare le interfacce risulta quasi necessario e fondamentale se nel gruppo di lavoro non ci sono esperti di mobile app. Il committente dello sviluppo oppure l’ideatore della mobile app probabilmente non avrà spiccate competenze in questo settore e mostrare loro come questo potrebbe visivamente svilupparsi significa risparmiare molto tempo ed eventuali fraintendimenti e discussioni future, che sono da evitare, emulando il metodo “What You See Is What You Get”, molto utile quando non tutti gli interessati al progetto sono dei tecnici ferrati in materia.

Cominciate con carta e matita, o direttamente con un software di gestione di elementi grafici; in rete troverete decine di siti web da cui scaricare gratuitamente o a basso costo tutti gli elementi grafici standard delle interfacce degli smartphone più diffusi. Come già accennato, esiste materiale da stampare su carta per creare dei veri e propri stencil, per disegnare velocemente interfacce differenti e testare i vari pulsanti e l’architettura in modo semplice e immediato; consiglio la carta soprattutto a chi, come l’autore, non ha grandi abilità con i software di grafica. Alternativamente, potete trovare già tutto il materiale in formato vettoriale (.ai e .psd sono i formati più diffusi in rete). La creazione della demo prototipo dovrebbe essere un passaggio obbligato non solo per chi utilizza gli elementi standard dell’ambiente di sviluppo, ma anche nel caso in cui per la vostra idea ci sia bisogno di interfacce costruite su misura e completamente personalizzate. In alcune tipologie di app come i giochi, ma anche app finanziarie, le interfacce e gli elementi grafici costruiti e pensati ad hoc per quella applicazione possono realmente decretarne il successo: se gli animali di “Hay Day” non fossero disegnati così bene e con una certa ironia, se le animazioni fossero piatte e prive di decorazioni, il gioco avrebbe avuto certamente meno successo.

La regola della personalizzazione delle interfacce non deve essere portata all’eccesso. A meno che la vostra idea non sia in un settore molto inflazionato, come citato precedentemente, concentratevi sulle funzionalità e sul design principale della vostra applicazione e utilizzate per tutti i comandi di navigazione il kit di interfacce standard presente in ogni ambiente di sviluppo. Se lavorate su un’app per iOS, leggete attentamente le linee guida di Apple e cercate di utilizzare lo User Interfaces Kit (o UIKit) che comprende tutte le tipologie di pulsanti e funzionalità standard native del dispositivo mobile; la stessa documentazione e relativi UIKit esistono anche per Android e per Windows.

Questa scelta vi permette in primo luogo di focalizzare i vostri sforzi nelle funzionalità e nella promozione dell’applicazione piuttosto che disegnare uno a uno ogni singolo pulsante di interfaccia e relativo codice. Inoltre gli utenti sono già abituati ai comandi standard delle interfacce in quanto le utilizzano quotidianamente per tutte le funzioni del device e in moltissime altre applicazioni che adottano gli UIKit, per cui comprenderanno molto più velocemente e più facilmente come navigare all’interno della vostra app, e la cosiddetta curva di apprendimento dell’utente sarà molto più breve e ridotta. In questo modo, gli utilizzatori della vostra app si concentreranno immediatamente e scopriranno subito le funzionalità che avete creato, senza impazzire all’interno di menu complessi ai quali non sono abituati; tutto ciò, ribadisco, a eccezione di settori con app molto simili in termini di funzionalità e di intrattenimento: in questi casi gli utenti stessi sono alla ricerca di creatività, estetica e design: quindi non deludeteli!

È fondamentale quindi sfruttare al massimo le potenzialità e la versatilità dei dispositivi mobili a disposizione; gli utenti amano molto l’utilizzo “smart” del loro device, sono abituati a ruotare lo schermo, piegarlo, utilizzare il touchscreen digitando, sfiorandolo con due o più dita, zoomando in avanti e indietro, tutti gesti ormai ai quali gli utenti sono abituati e che apprezzano particolarmente, perché esaltano il dispositivo stesso: non dimentichiamo che questi consumatori hanno investito un bel po’ di soldi nel loro gadget tecnologico preferito.

È importantissimo che tutto il gruppo di lavoro abbia confidenza con le potenzialità dei dispositivi per i quali si intende sviluppare la nostra idea. Una vera e propria “Bibbia” che dovete assolutamente leggere è quella di Apple: iOS Human Interfaces Guidelines, un PDF gratuito di oltre duecento pagine che può essere letto non solo per chi sviluppa in ambiente iOS, ma per chiunque sviluppi app per qualsiasi sistema operativo di dispositivi mobili. Almeno uno dei membri del gruppo di sviluppo potrebbe riportare un riassunto delle linee guida ai restanti membri, e tutti coloro che partecipano alla realizzazione dell’app devono essere consapevoli delle opzioni a disposizione, in termini di interfacce e interazione lato utente. Per questo motivo tutti devono perlomeno essere allineati sul linguaggio da utilizzare: anche se non siete dei tecnici, ma partecipate attivamente al progetto o ne siete i committenti, dovrete sapere che cosa è la status bar e che cosa significa fare una pagina di transizione. Quando volete costruire la casa dei vostri sogni e avete un’idea di come vorreste che fosse, siete in grado di comunicare con architetti, muratori, idraulici, elettricisti e così via perché sapete come si chiama, che cosa è e che funzione hanno una finestra, un balcone, una caldaia, un quadro elettrico; quando realizzate l’app dei vostri sogni, dovete riuscire a comunicare con chi la costruirà in concreto: siete voi che avete l’idea, non i grafici e i programmatori.

Purtroppo, molta terminologia è nuova anche nella lingua inglese; utilizzeremo sempre i termini originali in inglese delle linee guida con una possibile traduzione in italiano, a volte un neologismo, a volte parole tradotte diversamente in italiano. Ecco quindi una serie di definizioni degli elementi delle interfacce che dovete conoscere pur non essendo dei grafici.

Orientamento del dispositivo portrait o landscaping: una delle innovazioni di maggiore impatto del primo iPhone fu la possibilità di orientare a piacere il dispositivo e continuare a visualizzare in un nuovo formato le informazioni presenti sullo schermo.

Figura 5.2 – I dispositivi mobili hanno due tipologie di orientamento: portrait (verticale) e landscaping (orizzontale).

Quando sviluppate un’applicazione, il dispositivo indica all’app in che modo l’utilizzatore lo sta orientando e l’app stessa può adattarsi al nuovo orientamento o rimanere “bloccata”, oppure addirittura cambiare, attivando altre funzionalità. L’orientamento del dispositivo in verticale viene chiamato “portrait”, mentre quello in orizzontale si indica come “landscaping”. A meno che non stiate sviluppando un gioco, tenete ben presente tre indicazioni: in primo luogo non forzate l’orientamento del dispositivo: gli utenti devono avere la libertà di usare la vostra applicazione tenendo tra le mani il device come meglio credono. Spesso l’orientamento è definito dal contesto e non solo dal software: sulla metropolitana leggo le mail in modalità portrait e sdraiato sul divano faccio la stessa cosa orientando il telefono in modalità landscaping. Inoltre, fate comunque aprire la vostra app in modalità portrait se sviluppate per iPhone: molti utenti lanciano l’app da background utilizzando il tasto home dello smartphone; tutti gli iPhone accedono a questa funzione solo in modalità portrait, quindi i vostri utenti potrebbero rimanere disorientati nel caso incontrassero un’apertura orientata orizzontalmente. Infine, siate creativi e sfruttate l’orientamento dello schermo per mostrare maggiori contenuti lato utente oppure stupendo i vostri utilizzatori attivando una funzione utile e particolare. Due esempi perfetti sono l’app della Calcolatrice di Apple e quella di Yahoo! Finanza.

Figura 5.3 – L’app Calcolatrice di Apple: cambiando orientamento la calcolatrice standard diventa una potente calcolatrice scientifica.

La prima, cambiando orientamento del dispositivo, trasforma la calcolatrice standard in una scientifica, con tutte le opzioni a disposizione e molte più funzioni; la seconda attiva il grafico del titolo a schermo pieno e interattivo permettendo un’analisi tecnica semplice e veloce.

Figura 5.4 – L’app di Yahoo! Finanza: cambiando l’orientamento dello schermo, dai dettagli di un titolo azionario si accede al grafico interattivo a schermo intero.

Gesti, non clic: i moderni dispositivi mobili si controllano con le dita e presentano dei comandi gestuali standard che effettuano determinate azioni. È fondamentale sapere la terminologia di questi gesti:

•Tap: colpetto veloce del dito che emula il clic del mouse, la gestualità di base dei touchscreen.

•Doppio tap: doppio tocco veloce con un dito dello schermo che, normalmente, attiva e disattiva lo zoom.

•Drag: l’appoggiare un dito sullo schermo e trascinarlo sullo stesso. La funzione base per fare lo scroll di una pagina.

•Flick: lo stesso movimento del drag ma molto più rapido e veloce.

•Swipe: trascinamento con un dito dall’esterno dello schermo verso il centro col quale si possono aprire fnestre a comparsa e menu laterali, è il gesto che si usa per attivare la fnestra delle notifche in tutti i dispositivi iOS. Lo Swipe con più di un dito può attivare altre funzioni, per esempio il cambio di app in background.

•Pinch: il movimento a “pinza” eseguito con due dita per ingrandire o diminuire lo zoom dello schermo.

•Tap and Hold: il clic mantenendo la pressione sull’elemento. Esegue azioni diverse a seconda dell’oggetto selezionato, si attiva la lente di ingrandimento o il menu di selezione nel caso di testo, oppure salva un’immagine.

•Shake: è possibile ottenere degli eventi anche scuotendo il dispositivo.

È importantissimo sfruttare ove necessario queste gestualità nella vostra app, ma non abusatene a meno che non stiate creando un gioco dove la destrezza nei gesti è un elemento importante: Fruit Ninja ha spopolato grazie alla sua serie infinita di Flick.

Elementi di interfaccia standard

In primo luogo si definiscono quattro tipologie di barre:

Status Bar (Barra di Stato): elemento grafco in alto al dispositivo, dove sono presenti l’orario, la tipologia di connettività e lo stato della batteria. La Status Bar può essere nascosta dalla vostra applicazione: sconsiglio vivamente tale scelta in quanto la barra contiene alcune informazioni “vitali”, come l’orologio e il livello della batteria. A meno che non stiate sviluppando un videogioco o un’applicazione di distribuzione video, non nascondetela agli utenti e sacrifcate quello spazio della vostra app. È spesso possibile, ma non sempre (per esempio, sugli iPad), personalizzare i colori della barra di stato.

Figura 5.5 – Esempio di Status Bar.

Navigation Bar (Barra di Navigazione): normalmente posta al di sotto della barra di stato, questo strumento è il menu di navigazione gerarchica della vostra applicazione. Su questa barra è presente il nome della sezione visualizzata, la possibilità di tornare nella sezione precedente, cliccando sul pulsante a sinistra e di eseguire azioni con un comando alla destra del nome della barra di navigazione. Utilizzate sempre le modalità e i comandi standard delle interfacce quando costruite le vostre Navigation Bar: gli utenti sono già abituati a utilizzare strumenti identici in molte altre applicazioni. Non cambiate le regole del gioco: i vostri utenti sembreranno tutti degli automobilisti inglesi sulle strette stradine toscane, disorientati dalla guida a destra oltre che dal meraviglioso paesaggio.

Figura 5.6 – Esempio di Navigation Bar.

Toolbar (Barra degli Strumenti): questa barra contiene tutte le azioni e gli strumenti che possono essere eseguiti in relazione al contenuto visualizzato dall’utente in quel momento. La Toolbar è posizionata in alto o in basso allo schermo, a seconda dei dispositivi, e sostituisce o si implementa all’interno della barra di navigazione. Questa barra dovrebbe contenere le scorciatoie alle funzionalità più utilizzate dai vostri utenti. Può utilizzare pulsanti standard, ma anche essere personalizzata per integrarsi meglio al layout della vostra applicazione, tenendo sempre presente che gli utenti sono abituati a Toolbar e pulsanti standard e conoscono già molti simboli quali il cestino per cancellare, il rettangolo con freccia per inviare le informazioni a schermo e così via; non stravolgete quindi anche i simboli standard.

Figura 5.7 – Esempio di Toolbar.

Tab Bar: è l’ultima tipologia di barra utilizzata nei dispositivi mobili; questa barra, posizionata in basso allo schermo, dovrebbe essere sempre presente durante l’utilizzo dell’app e dovrebbe mostrare le sezioni più utili dell’applicazione stessa, oppure una visualizzazione dell’informazione da un altro punto di vista. Se sviluppate per smartphone non avrete comunque a disposizione molti spazi (su iOS sono massimo 5 tab, dopodiché il sistema crea in automatico il tab More). Elemento molto interessante della Tab Bar è la possibilità di visualizzare direttamente sui tab i badge: il numero che indica una notifca o un aggiornamento collegato a uno specifco tab.

Figura 5.8 – Esempio di Tab Bar.

Un’altra serie di termini specifici da conoscere per poter dialogare con chi disegna le interfacce e che definisce modi differenti per visualizzare il contenuto della vostra applicazione e l’interazione con app di terze parti o elementi standard del dispositivo mobile è la seguente:

Activity View (Visualizzazione Azioni): potete creare un’azione in relazione al contenuto visualizzato a schermo. Una volta selezionato il contenuto attraverso il touch, l’utente può, attraverso l’Activity View, inviarlo via mail, condividerlo su un social network, stamparlo ecc. In tutti i principali sistemi operativi mobili, le attività vengono attivate tramite un pulsante di sharing.

Figura 5.9 – Esempio di Activity View.

A seconda del contenuto e dell’app, possono cambiare le possibilità: è difficile stampare un file audio, così come riprodurre il suono di un’immagine; con questo tipo di visualizzazione potete creare delle attività personalizzate relative al contenuto della vostra applicazione e potete gestire anche l’interazione tra la vostra app e quelle di terze parti. Un’app di gestione di fotografie potrebbe permettere la condivisione delle immagini direttamente sui social network, oppure inviarle all’app di Dropbox o mandarle in stampa e così di seguito. Personalizzate solo le attività specifiche della vostra applicazione ma non modificate le azioni standard né in termini di nomi né tantomeno in termini di icona, non confondete gli utilizzatori della vostra applicazione quando compiono azioni a cui sono già abituati.

Image View (Visualizzazione Immagine): è la fnestra che visualizza una o più immagini all’interno del dispositivo.

Map View (Visualizzazione Mappa): è la modalità di visualizzazione della mappa built-in del sistema operativo.

Scroll View (Visualizzazione con Scorrimento): fnestra che fa lo scroll verticale, ma anche orizzontale (assolutamente non consigliato).

Popover (Finestra Sovraimpressa): normalmente disponibile sui tablet, piuttosto che negli smartphone, il Popover permette di aprire una fnestra sovraimpressa rispetto al contenuto a schermo; può essere un menu, ma anche un’altra tipologia di contenuto, come una mappa o una fnestra di input di testo.

Figura 5.10 – Esempio di Popover.

Quando utilizzate la funzione di Popover, è importante non coprire tutto il contenuto a schermo: in questo caso non avreste bisogno di un Popover, ma dovreste utilizzare una nuova scheda. Il Popover sostituisce anche lo Split View, quando il dispositivo viene orientato in modalità portrait.

Split View (Visualizzazione Divisa): presente sui tablet e quasi assente negli smartphone, questa modalità permette allo sviluppatore di dividere lo schermo in due sezioni separate con scorrimento autonomo, ma che interagiscono tra di loro; lo Split View più conosciuto è quello della gestione della posta elettronica: una fnestra mostra gli oggetti e i mittenti delle mail, mentre l’altra mostra il contenuto della mail selezionata.

Figura 5.11 – La Split View di Mail su iPad, molto comoda per la gestione operativa della posta elettronica.

Normalmente la sezione di sinistra dovrebbe essere quella di navigazione, mentre quella di destra dovrebbe essere il contenuto completo relazionato; per questo motivo lo Split sinistro dovrebbe essere più ridotto rispetto al destro e dovete sempre permettere agli utenti di nascondere la sezione di sinistra in modo da focalizzare la propria attenzione sul contenuto specifico.

Table View (Visualizzazione a Tabella): questa tipologia di visualizzazione dei dati è una di quelle più utilizzate per la navigazione in gruppi di dati e informazioni, presente in svariate applicazioni: dalla rubrica del telefono, alle scelte delle impostazioni.

Si distinguono principalmente due tipologie di tabelle: Plain e Grouped; le prime presentano un’intestazione e una chiusura, mentre le seconde hanno diverse intestazioni e sottotitoli. Inoltre, è possibile aggiungere un indice “galleggiante”, posto in verticale sulla destra della tabella, per accedere velocemente ai vari contenuti presentati in modo gerarchico; l’indice può essere gestito a piacere, ma normalmente consiglio quello classico alfabetico o numerico.

Figura 5.12 – La Table View è una delle visualizzazioni più utilizzate in ambiente mobile.

Quando si sfruttano queste tipologie di visualizzazioni è di fondamentale importanza l’utilizzo degli oggetti e dei gesti standard degli utenti, in modo da permettere un ambiente già conosciuto ai vostri utilizzatori; ricordate che questo tipo di visualizzazione è tra le più frequenti nel mondo delle app. Utilizzate quindi i seguenti comandi e simboli standard:

•Checkmark: indica che la riga della tabella è stata selezionata.

•Disclosure Indicator: indica che, selezionando quella riga, si accede a una seconda tabella gerarchicamente inferiore rispetto all’attuale.

Figura 5.13 – Checkmark, Disclosure Indicator e Row Reordinator della Table View.

•Detailed Disclosure Button: questo pulsante indica che, selezionando la riga della tabella, si potrà accedere a una scheda di dettaglio della riga selezionata.

•Row Reordinator: questo simbolo permette di spostare, se possibile, la posizione di una riga rispetto a un’altra semplicemente trascinando la riga stessa.

•Row Insert e Delete: questi simboli, da non personalizzare mai, servono per aggiungere o cancellare una o più righe alla tabella.

Modal View (Visualizzazione Modale): utilizzata moltissimo nei dispositivi iOS, ma anche molto presente in quelli Android, questa tipologia di interazione permette l’apertura di una fnestra, normalmente per l’inserimento di testo, in modalità “galleggiante” rispetto allo schermo; utilizzate questa visualizzazione quando per esempio mandate un messaggio via mail, ma anche un sms.

Figura 5.14 – La Modal View in azione durante l’invio di una mail da tablet.

Controlli: è di fondamentale importanza, per rendere usabile il più possibile la vostra applicazione, utilizzare tutta una serie di elementi grafci, defniti genericamente “controlli”, per fornire informazioni all’utente così come per farlo interagire in modo rapido, veloce e intuitivo all’interno della nostra applicazione. Ecco di seguito i controlli più importanti e utili lato utente che dovete sempre ricordare.

Indicatore di Attività: nel caso in cui la vostra applicazione esegua delle operazioni che richiedono del tempo per essere elaborate dal device, è di fondamentale importanza fare percepire all’utente che è in corso un’operazione e che la vostra app sta elaborando delle informazioni e il dispositivo non è bloccato.

Progress View: nel caso in cui l’elaborazione delle informazioni o un caricamento di informazioni sia un’operazione prolungata, è decisivo mostrare ai vostri utenti lo stato di avanzamento dell’operazione in corso in modo da fare comprendere immediatamente i tempi di attesa.

Data Picker: nel caso in cui la vostra app necessiti l’inserimento di una data da parte di un utente, è molto importante utilizzare questo tipo di controllo per rendere più agevole e rapido l’inserimento di questa tipologia di informazioni. Il Data Picker può essere con data, orario, data e ora o conto alla rovescia. Può essere modifcata la granularità di questi controlli; normalmente, un’ora è suddivisa in sessanta minuti, ma è possibile personalizzare questi aspetti e fare suddividere, per esempio, l’ora in quattro blocchi da 15 minuti.

Picker: questa tipologia di controllo permette la selezione di un elemento in modo rapido ed effciente; è possibile inserire una serie di etichette a piacere e personalizzate per le necessità della vostra applicazione. L’utilizzo dei Picker è fondamentale anche per evitare errori di digitazione e mantenere le scelte di un utente in un ambiente “controllato”. Nel caso in cui la lista delle possibilità sia molto ampia, potrebbe essere più utile l’utilizzo di una visualizzazione a tabella piuttosto del Picker. Anche quando parliamo di web app o m-site, è molto importante riuscire a fare compilare i form in modo semplice e veloce e quindi collegarsi al Data Picker e al Picker del browser per rendere la compilazione degli input dei form più semplice, veloce ed effcace lato utente.

Refresh Control (Controllo di Aggiornamento): nel caso in cui la vostra app funzioni con una serie di informazioni in continuo aggiornamento, utilizzate questo tipo di controllo. Lo standard è stato introdotto da Apple, ma viene ormai usato anche in tutti gli altri sistemi operativi mobili, ed è presente in tutte le app che fanno del tempo reale e dell’aggiornamento costante dei dati una delle loro principali caratteristiche. Questa funzione è legata a un gesto e non a un pulsante: gli utenti trascinano verso il basso il contenuto a schermo per richiedere un aggiornamento dello stesso. L’utilizzo del controllo di aggiornamento non deve comunque inibire il push automatico delle informazioni, che dovreste utilizzare in modo periodico con intervalli variabili a seconda della tipologia del contenuto. Una quotazione di borsa potrebbe venire aggiornata ogni venti secondi oppure una volta al minuto, mentre quella relativa agli aggiornamenti di un social network potrebbe essere impostata ogni due minuti. Con il Refresh Control potete lasciare la libertà all’utente di aggiornare manualmente le informazioni a seconda del livello di bisogno di aggiornamento. Se sto per acquistare un titolo azionario in un determinato momento, per decidere il momento migliore della compravendita avrò bisogno dell’informazione aggiornata quasi ogni secondo.

Se invece devo controllare il mio portafoglio azionario, un aggiornamento anche poco frequente non sarà un problema. La scelta, con il Refresh Control, è in mano all’utente che deciderà in autonomia a seconda del contesto in cui si trova.

Figura 5.15 – Il Refresh Control di Twitter: questo social network si rapporta con il tempo reale e vive in tempo reale; la sua app è stata una delle prime a integrare questa funzionalità. Trascinando lo schermo verso il basso, compare una freccia verticale e l’app aggiorna la schermata in corso.

Search Bar (Barra di Ricerca): pur essendo una barra, questo elemento viene classifcato all’interno dei controlli. Una barra di ricerca si attiva con un tap, e permette l’inserimento di un testo. È possibile e consigliato l’inserimento di un cosiddetto “placeholder”, ovvero un testo di default all’interno della barra per comprendere meglio la tipologia di ricerca che può essere fatta: dal semplice “cerca” per ricerche generiche a testi appropriati al tipo di ricerca e al contenuto della vostra applicazione. Se sviluppate un’app di hotel, il placeholder potrebbe essere “località” oppure “nome hotel” o entrambi. Il placeholder è molto utile per non creare ricerche non allineate con il contenuto che erogate. Altro elemento opzionale, ma importante della barra di ricerca è il pulsante per cancellare, con un solo tap, il contenuto di testo all’interno della barra. Cancellare testi lunghi di ricerche precedenti può essere poco usabile e fastidioso per l’utente, quindi agevolate il più possibile chi usa la vostra app. L’ultimo consiglio è di tenere in memoria l’ultima o le ultime ricerche effettuate dall’utente, così come permettere di salvare determinate ricerche.

Scope Bar (Barra di Scopo): questa barra è utilizzabile solo insieme a quella di ricerca e fornisce una funzione di fltro rispetto alla ricerca eseguita; se sviluppate un’app turistica potreste fare specifcare nella barra di scopo se la ricerca testuale deve essere eseguita tra tutti gli elementi della vostra applicazione oppure solo per gli hotel o i campeggi o i bar e così via.

Segmented Control (Controllo Suddiviso): questo tipo di pulsanti deve essere utilizzato quando, a seconda della selezione, il contenuto a schermo e la tabella raggruppata si modifcano.

Slider: questo controllo permette di gestire una funzione in modo molto visuale ed estremamente intuitivo per gli utenti. Lo Slider più banale è quello che regola la luminosità di uno schermo, ma la vostra creatività può elaborare una serie infnita di Slider.

Stepper: un altro pulsante di controllo molto utile che incrementa o decrementa un determinato valore di inserimento secondo una scala personalizzabile. Molto utile, come lo Slider, per evitare inserimenti da tastiera.

Switch: un controllo da usare in caso di scelte a due possibilità, sostanzialmente un interruttore in modalità on/off, ma che può avere moltissime applicazioni in differenti situazioni. Anche in questo caso lo Switch è molto comodo per evitare inserimenti da tastiera o check button.

Cose da sapere… anche se non sei un programmatore

Oltre alle conoscenze relative agli aspetti grafici, è molto utile avere ben chiari alcuni aspetti tecnici e di funzionamento dei dispositivi mobili, anche se non avete mai visto una linea di codice nella vostra vita.

Innanzitutto dovete avere ben chiara la differenza tra un’applicazione che funziona anche in locale e un’app che funziona solo se collegata alla rete: per comprendere ciò non dovete avere nessuna conoscenza di codice, ma semplicemente capire come funziona la vostra applicazione. Le informazioni e i contenuti che offrite hanno bisogno di aggiornamenti? Un libro di nomi di piante viene aggiornato dopo alcuni anni, un catalogo di mobili dopo pochi mesi, una previsione meteorologica dopo qualche ora, un titolo azionario ogni secondo. Dovete capire se tutto o parte del vostro contenuto ha bisogno di Internet per funzionare: un videogioco potrebbe essere utilizzato senza la rete giocando in modalità giocatore singolo, mentre avrebbe necessariamente bisogno della connessione per giocare contro altri avversari in Internet. Nel caso in cui la vostra app funzioni quasi esclusivamente online, dovreste anche creare un m-site con le medesime funzionalità ottenendo certamente economie di scopo e di scala sviluppando contemporaneamente entrambe le soluzioni. Nel caso in cui la vostra applicazione funzioni completamente, o quasi, anche offline dovete comprendere quanto sia il peso del contenuto delle informazioni presenti: ricordate sempre che il peso del contenuto dipende soprattutto da quanti elementi multimediali è costituito: il puro testo occupa pochissimo spazio, le immagini in alta risoluzione e i video in HD sono contenuti molto pesanti. Possiamo sintetizzare questo ragionamento con il seguente piano cartesiano e analizzando gli scenari più comuni.

In questo senso isoliamo quattro distinti scenari possibili a seconda della posizione della vostra app all’interno del piano cartesiano. Otteniamo quindi gli scenari della Tabella 5.3.

Figura 5.16 – Piano cartesiano per comprendere il posizionamento della propria applicazione in termini di pesantezza del contenuto erogato.

A Funziona soprattutto online + contenuti leggeri | C Funziona soprattutto offline+ contenuti leggeri
B Funziona soprattutto online + contenuti pesanti | D Funziona soprattutto offline + contenuti molto pesanti

Tabella 5.3 – I quattro scenari in termini di pesantezza del contenuto e necessità di connettività.

Scenario A: il vostro software dipende fortemente dalla presenza di connessione, tenetelo sempre presente: l’app non funzionerà nelle zone non coperte dal servizio dati e all’estero in mobilità (quasi sempre); potete interagire molto più spesso con i vostri utenti e in tempo reale fornendo notifche e cambiando contenuti in modo continuativo e probabilmente anche il layout dello stesso. Siete molto avvantaggiati nell’informare i vostri utilizzatori di modifche, aggiornamenti e lanci di nuove applicazioni, perché i vostri utilizzatori quando usano la vostra app sono connessi alla rete e quindi siete sicuri di poter comunicare con loro. Infne cercate di tenere una cache molto ampia della vostra applicazione: in questo modo potrete permettere agli utenti di ottenere perlomeno le ultime informazioni visualizzate anche in caso di mancanza totale della rete. Non fate come faceva il browser Safari su iOS prima dell’aggiornamento alla versione 7 che, se non aperto da molto, cercava di ricaricare la pagina a schermo perdendone completamente il contenuto già presente. Anche adesso il browser può avere queste problematiche, ma in modo molto inferiore rispetto alle versioni precedenti.

Scenario B: la vostra app dipende dalla rete e i vostri contenuti sono molto pesanti; questo è lo scenario peggiore nel quale potete essere. Dovete focalizzare molta attenzione nella parte architetturale di sviluppo della vostra app, perché restare in questo scenario è estremamente pericoloso, tanto da poter mettere in forte dubbio lo sviluppo dell’applicazione stessa. Cercate di spostarvi nello scenario D o in quello A, ma non rimanete in B se proprio non siete costretti. Restare in B signifca fare un’applicazione che funziona praticamente solo in modalità wi-fi, qualcosa per tablet casalinghi, come un ricettario di videocucina, ma ribadisco la pericolosità della scelta. Lo scenario B è spesso presente nelle applicazioni B2B e, in questi casi, risulta ammissibile; cercate comunque di ottimizzare al massimo la pesantezza del contenuto e comprendere veramente che cosa ci sia da mantenere costantemente aggiornato e che cosa invece potreste pensare di aggiornare di tanto in tanto. In un catalogo di mobili potreste dover aggiornare prezzi e disponibilità delle varie referenze quotidianamente, ma le immagini, i video e le caratteristiche dei mobili rimangono sempre le stesse fno all’introduzione del nuovo catalogo. Potreste quindi pensare di far aggiornare (magari in uffcio o nelle abitazioni in wi-fi) il catalogo con le sole disponibilità di prezzi e sconti quotidianamente da parte della vostra rete agenti, mentre tutto il resto dell’applicazione potrebbe venire aggiornata ogni sei mesi. Il peso degli aggiornamenti quotidiani è un infnitesimo rispetto al resto del catalogo. Riesco quindi a cambiare scenario selezionando selettivamente il contenuto che necessita di un reale aggiornamento e posso addirittura trasformare la mia applicazione da “connettività-dipendente” a offine senza bisogno di rete.

Scenario C: è la situazione più semplice, un’app leggera che funziona senza Internet. Anche in questo scenario ci possono essere alcune insidie; se siete completamente offine non avete modo di interagire con il vostro utente a meno che non abbia abilitato le notifche, ma se la vostra app serve offine, probabilmente il vostro utilizzatore non vi ha dato il permesso di inviargli notifche. Questo scenario allontana un po’ gli sviluppatori dall’utente, per questo motivo vi fornisco due consigli per spostare la vostra applicazione verso lo scenario A. In primo luogo inserite, al lancio della vostra applicazione o all’interno, uno spazio che necessiti comunque di connessione, una specie di “fnestra sulla rete”. Con un codice molto semplice potrete decidere di visualizzare un contenuto non in rete in caso di mancanza di connettività, oppure delle informazioni di qualsiasi tipo in caso di presenza della connessione. In questo modo manterrete tutte le funzionalità della vostra applicazione integre anche offine, ma potrete interagire e comunicare con i vostri utenti quando questi sono online. In secondo luogo, cercate di fare andare online l’utente anche se non avrebbe necessariamente bisogno di farlo per usare la vostra app. Un esempio classico è presente in moltissimi videogiochi per dispositivi mobili; posso giocare tranquillamente da solo, ma con la connessione posso ottenere bonus, caricare i miei record confrontando i miei risultati con quelli di altri utenti, vedere le classifche e così via. In questo modo lascerete intatta la vostra idea videoludica, ma fornirete degli incentivi agli utenti per andare online e, una volta online, per interagire con essi anche solo per aggiornarli della nuova app che avete sviluppato.

Scenario D: questo è lo scenario nel quale si trovano moltissime applicazioni di videogame. Il loro nemico sono i megabyte e gli avversari i titoli famosi e tutte le trasposizioni di giochi da computer e consolle che possono occupare molti megabyte. L’utente li scaricherà connesso con una ADSL, o addirittura sul desktop, direttamente dall’app store, e non ci sono enormi problematiche, anzi, un gioco famoso con tanta grafca che pesa solo qualche decina di megabyte potrebbe indurre il consumatore a un non acquisto, in quanto sembra un po’ “scarno” in termini di pesantezza e quindi a volte è percepito come un gioco che si fnisce in poco tempo. Nel caso invece di giochi non famosi che non richiedano enormi sforzi grafci e non presentino centinaia di scenari diversi, la lotta contro i megabyte è fondamentale. L’obiettivo principale è quello di rimanere sotto la soglia dei 50 MB (fno a inizio 2012 era di 20 MB): questo perché gli app store non permettono il download di app con un ingombro superiore ai 50 MB e richiedono necessariamente una connessione via wi-fi del dispositivo. Inizialmente Apple App Store aveva imposto la soglia di 20 MB e la casa di Cupertino aveva ricevuto moltissime critiche per questa scelta da parte degli sviluppatori. Che esista o meno una soglia, ritengo comunque utile ricordare che il download di un oggetto di 45 MB via 3G può essere veramente lento e frustrante per l’utente in mobilità, che cercherà quasi certamente alternative valide alla vostra applicazione che pesino di meno. In questo caso è necessario uno sforzo continuativo da parte di tutto il team di lavoro nell’ottimizzare al massimo tutti gli elementi del software per ridurre al minimo la pesantezza dello stesso. È fondamentale un lavoro coordinato da parte di tutti anche a livello di concept iniziale. Si dovrebbe pensare a come eventualmente suddividere il contenuto e lasciare parte dello stesso opzionale ed eventualmente scaricabile in un secondo momento da parte dell’utente: lo spazio è essenziale.

Un settore che ha affrontato abbondantemente questa tipologia di problematiche è quello delle applicazioni con mappe che permettono la propria geolocalizzazione. Se penso a un’app per fare conoscere i sentieri e le camminate della mia regione, potrei pensare di tenere le mappe nell’applicazione piuttosto che lasciarle online e richiedere al dispositivo mobile di connettersi e inviarmi la mappa mano a mano che cammino. Ma spesso in montagna sono in luoghi dove il segnale di rete non è disponibile o è molto scarso. In questi casi potrei quindi decidere di inserire le mappe dei sentieri all’interno dell’applicazione stessa. Le mappe già scaricate con l’applicazione hanno il vantaggio estremo di funzionare sempre, anche senza segnale e soprattutto molto utili a tutti i viaggiatori che arrivano dall’estero e che quasi sempre non utilizzano, perlomeno non costantemente, il famigerato roaming dei dati, per evitare di incorrere in costi enormi sulla bolletta o in addebiti astronomici sulla carta di credito. Lo svantaggio delle mappe offline è però il loro peso: una mappa dettagliata con tante indicazioni può essere molto pesante in termini di megabyte; inoltre nel caso di errori o problemi con alcune aree della mappa, l’utente la vedrà corretta solo se scaricherà e aggiornerà nuovamente l’app. Nelle mappe online ogni correzione è subito aggiornata e disponibile per tutti. Infatti la maggior parte dei software di mappe funziona solo se connessi alla rete (da Google Maps a Mappe di Apple, sino a Waze), questo anche perché le mappe del mondo intero sono un po’ pesanti e quindi il download dell’app risulterebbe molto lungo e il software occuperebbe molto spazio sul device dell’utente. Ma DirectU, sviluppato da NNG Global, ha voluto diversificarsi proprio andando nella direzione opposta: ha suddiviso il mondo in continenti e fornisce mappe offline: ogni area geografica pesa oltre 1gigabyte, le mappe sono bellissime, l’app non ha funzioni di navigazione, ma proprio di cartina geografica, con il vantaggio enorme di sapere sempre dove ci si trova all’interno della cartina attraverso il segnale GPS. Queste mappe sono orientate alle attività all’aria aperta, in località spesso isolate e senza segnale di rete: un evento non raro per chi ama la natura e adora inoltrarsi in boschi, montagne e foreste; il GPS è sempre presente e sempre utilizzabile, ideale per chi svolge attività outdoor a eccezione forse della speleologia. Un secondo punto di forza di DirectU e del suo essere offline è rivolto a tutti i viaggiatori e i turisti esteri: a chiunque sarà capitato di viaggiare all’estero con il proprio o i propri dispositivi mobili e di essere incappato nelle stratosferiche tariffe del roaming internazionale; per questo motivo quasi tutti i viaggiatori stanno molto attenti e non utilizzano il traffico dati quando sono all’estero. In questo modo quasi tutte le applicazioni di mappe presenti nei loro dispositivi non funzionano proprio nel momento di massimo bisogno, dato che conoscono poco questi luoghi, rispetto a quelli della propria nazione, e a volte faticano ad adattarsi a un nuovo modello di segnaletica. Per questo motivo sono fiorite applicazioni di mappe offline per il turista, che permettono un download selettivo e intelligente della località: vuoi andare a fare un weekend romantico a Parigi? Scarichi solo la mappa della capitale francese e decidi addirittura se downloadare schede aggiuntive informative di musei, ristoranti, trasporti e così via. In questo modo riesco a ottenere i vantaggi di entrambe le soluzioni: non appesantisco molto il download iniziale della mia app, perché all’inizio è sostanzialmente un mero software di gestione di interfacce, e poi decido a piacere quante e quali mappe aggiungere alla mia collezione, in modo da spezzettare i gigabyte di spazio occupati da una mappa di tutto il mondo in tante piccole cartine geografiche, lasciando che sia l’utente a decidere. Niente di nuovo sul fronte occidentale: pensando alle guide turistiche, non comprate la guida del mondo (se esistesse, sarebbe altresì un volume poco tascabile di decine di migliaia di pagine), ma acquistate di volta in volta la guida del Paese o della città che intendete visitare. Una volta terminato il viaggio, regalate o prestate la guida a un amico (quasi sempre il prestito di guide turistiche si tramuta in regalo) oppure la mettete su una mensola, affiancata a tutte le altre, e ogni volta che ci passate davanti vi ritornano in mente tutti i vostri viaggi e le vostre avventure. Il mondo digitale è uno specchio del mondo analogico, ci sono tante sfumature che li rendono differenti, ma la sostanza e l’essenza della natura umana sono sempre le stesse, accelerate e rese più interconnesse dalla rete, ma siamo pur sempre persone che “tappano” e “pinzano” schermi touch.

Un secondo concetto che dovete avere presente anche se non siete dei programmatori è quello del multitasking, come funziona e come potete gestirlo.

Gli utenti non solo utilizzano tante applicazioni, ma spesso lo fanno anche contemporaneamente; i dispositivi mobili gestiscono normalmente un’app alla volta a schermo. Quando un’applicazione viene attivata si pone in primo piano rispetto a tutte le altre, ma quando viene chiusa ci sono normalmente due modalità: una definitiva e una temporanea. Nel primo caso il software smette di lavorare completamente e non viene elaborato nessun dato e nessuna informazione, nel caso della chiusura temporanea, l’applicazione viene posta in una sorta di limbo che si definisce background il dispositivo potrebbe continuare a elaborare le informazioni dell’applicazione, pur non concentrando tutta la sua potenza di calcolo, ma diciamo che l’app continua a rimanere in uno stato di sospensione e funzionamento in secondo piano. Così un software che esegue brani musicali potrebbe continuare a funzionare anche mentre l’utente scrive una mail e un’app di tracking GPS, come quella dello sci già presentata, sarà sempre in funzione anche mentre chiamo o mando messaggi via WhatsApp dalla seggiovia.

La possibilità di avere comunque un’elaborazione continua, almeno di una parte delle informazioni, è molto utile e da tenere presente: la vostra app potrebbe essere tenuta in sospeso e non chiusa completamente. La riapertura e la chiusura dell’applicazione deve essere dolce e non immediata, la musica deve sfumare ed è comunque utile presentare una pagina, anche solo di un secondo, di finto caricamento delle interfacce per rendere la transizione più gradevole all’utente. Nel caso la vostra app utilizzi molto anche altri elementi standard come foto, telefonate e messaggi, considerate che gli utenti spesso passeranno da queste applicazioni alla vostra. Fate numerose prove per vedere come le vostre interfacce si adattano, per esempio, durante una conversazione telefonica oppure con la libreria delle immagini.

Un ultimo concetto tecnico che tutto il gruppo di lavoro deve comprendere completamente è il sistema di notifiche tramite dispositivi mobili che avete a disposizione. Il sistema di notifica mobile è un nuovo modello di comunicazione tra sviluppatori e utilizzatori di applicazioni che permette, seppur a distanza, una possibilità di contatto continuativo con l’utente. Il sistema di notifica permette l’invio di messaggi, spesso sotto forma di testo, verso un dispositivo mobile che li riceve automaticamente senza bisogno di alcun gesto da parte dell’utente. Il primo modello di notifica nei cellulari, ben prima della nascita degli smartphone, era l’avviso dell’arrivo di un sms sullo schermo del telefono con il nome del mittente se in rubrica.

Esistono due principali tipologie distinte di notifiche dei dispositivi mobili:

Local Notifcation (Notifca Locale): l’informazione, precedentemente registrata dall’app oggetto della notifca viene inviata direttamente dal sistema operativo al dispositivo stesso a prescindere che l’app sia attiva, in background o non attiva. Un esempio banale sono tutti gli avvisi di app calendario e liste di cose e attività da fare pianifcate: impostando un avviso all’interno di una di queste app, a una certa data e a una determinata ora, l’applicazione invierà una notifca locale nell’istante precedentemente preimpostato.

Figura 5.17 – Esempio di Local Notification di un promemoria di un’agenda.

Push Notifcation (Notifca Remota): l’informazione viene normalmente inviata dai server degli sviluppatori dell’applicazione spesso passando dai server dello store o del sistema operativo per questioni di sicurezza, e poi arriva al dispositivo dell’utilizzatore fnale. In tutti i casi di notifche di tipo Push, nei primi utilizzi l’app dovrà chiedere all’utente se inviargli le notifche oppure no e sarà l’utente a decidere se accettare o declinare e, talvolta, anche la tipologia grafca della notifca (Figura 5.18).

Proprio per il fatto che è sempre l’utente a decidere se rimanere in comunicazione con la vostra app e in un certo qual modo con gli sviluppatori stessi, anche mentre non sta usando l’app, è importante gestire il timing delle vostre notifiche. Non subissate i vostri utenti con push continui, li disattiveranno immediatamente, a meno che non siano essenziali, e addirittura potrebbero cancellare la vostra applicazione, in quanto troppo “intrusiva”.

Figura 5.18 – Esempio di Push Notification.

Dovete dosare le notifiche e permettere agli utenti di selezionare i giorni della settimana e gli orari in cui le vuole ricevere o meno; alcune app, in modo molto intelligente, arrivano addirittura a fare scegliere all’utente un livello di numerosità a piacere (molte app editoriali sono così). Il layout delle notifiche, siano esse local o push, appartiene sostanzialmente a tre tipologie principali:

Notifca a Banner: sostanzialmente un messaggio a comparsa, normalmente nella parte superiore del dispositivo; il banner può contenere il logo e il nome dell’app e una preview della notifca. Questa notifca cattura l’attenzione temporanea dell’utente, pur rimanendo poco invasiva poiché scompare dopo pochissimi istanti.

Notifca ad Alert: la più classica, in quanto presente ben prima dell’invenzione degli smartphone; ancora adesso assume lo stesso layout delle notifche degli sms, per questo motivo è quella che cattura di più l’attenzione dell’utente. Se utilizzate questo stile, siate parsimoniosi con il numero di notifche.

Notifche a Badge: il badge è un’etichetta che viene apposta sul logo della vostra applicazione che segnala la presenza di una o più informazioni notifcate all’interno di quell’app. Il badge è il sistema di notifca meno invasivo nel breve periodo in quanto può risultare addirittura invisibile subito all’utente, ma può diventare molto noioso nel medio lungo-periodo, poiché il badge non scompare fnché l’applicazione non viene lanciata e l’informazione notifcata. Considerando che il badge, nel caso l’app sia all’interno di una cartella insieme ad altre, viene trasferito dall’icona dell’applicazione a quella della cartella e cumulato con le altre, la persistenza dello stesso può portare alla cancellazione di un’app poco usata ma utile, solo per colpa delle eccessive notifche.

Oltre al design, gli sviluppatori possono aggiungere o meno dei suoni alle notifiche che vengono eseguite. Anche in questo caso, il mio consiglio è di fare estrema attenzione all’utilizzo dei suoni, che sono molto invasivi soprattutto in orari lavorativi e notturni. L’uso di notifica più suono deve essere valutato con calma e considerando gli svantaggi oltre ai vantaggi: il vostro messaggio arriverà quasi certamente, ma l’effetto potrebbe essere diametralmente opposto rispetto a quello desiderato. Se dovessi ricevere una offerta dell’hotel che stavo per prenotare col 20% di sconto da un’app di prenotazione alberghiera alle 4 di mattina, potrei decidere di cancellare immediatamente l’applicazione nonostante avessi un chiaro beneficio economico.

Test di usabilità

Una delle splendide massime di Einstein recita: “Non hai compreso qualcosa fino a quando non sei in grado di spiegarlo a tua nonna”. Come sempre lo scienziato tedesco riesce a sintetizzare in modo perfetto un concetto che possiamo prendere in prestito per il test delle applicazioni: non avete sviluppato abbastanza bene la vostra applicazione fintanto che anche vostra nonna non sarà in grado di utilizzarla. A parte le dovute eccezioni, soprattutto in ambito ludico, questa dovrebbe essere la regola.

Un’applicazione deve essere in primo luogo fruibile dal maggior numero di persone, a prescindere dal loro livello di praticità col dispositivo, perlomeno per coloro che ne possiedono uno, indipendentemente dall’età o dal sesso, ma anche dal livello di istruzione e culturale. L’app perfetta dovrebbe essere come la legge: uguale per tutti… in termini di usabilità, chiaramente.

La semplicità di utilizzo deve aumentare ancora di più nel caso in cui la vostra app venga utilizzata realmente in mobilità, mentre cammino, mentre scio, mentre corro. Il vostro software dovrà sapersi adattare a contesti limitanti: utilizzo con una sola mano, tapping col solo dito pollice ecc.

È di fondamentale importanza testare l’applicazione e tutte le sue funzionalità prima di caricare la versione 1.0 negli store e soprattutto prima di ogni aggiornamento. Ogni versione deve essere testata a fondo e non solo la nuova parte di codice o le nuove funzionalità, bensì tutta l’app. Potete aver avuto la migliore idea del mondo, potete aver disegnato le interfacce più belle e inventato funzionalità uniche, ma se la vostra applicazione dovesse “crashare” spesso, non avrete futuro, anzi, qualcun altro potrebbe evolvere la vostra idea, ma in modo migliore e più funzionale e ottenere successo alle vostre spalle: voi avete avuto l’idea, ma la vostra app si blocca una volta su tre, altri la rifaranno meglio di voi. Sciacalli di applicazioni, non dategli spazio! Tutto solo per non aver testato a fondo. Se vendete un software e questo non funziona, anche solo parzialmente, i vostri clienti vi subisseranno di recensioni molto negative e, anche una volta corretto il problema, quei voti e quei giudizi rimarranno per sempre. Una macchia indelebile con una diminuzione perpetua del voto globale dell’app. Spesso il team di sviluppo è ansioso di uploadare la propria creazione e di vedere quanti la scaricheranno; siamo tutti emozionati il giorno dell’inaugurazione, ma l’emozione e la fretta vanno tenuti a freno, soprattutto nel caso in cui sia stato cambiato parte del codice anche il giorno stesso della sottomissione agli store.

I test di usabilità devono iniziare molto prima, fin dalla versione Alfa della vostra applicazione. Definiamo, come avviene sostanzialmente per tutti i software, almeno due momenti di sviluppo: momento (e versione) Alfa e momento (e versione) Beta del progetto. La versione Alfa presenta l’applicazione con le sue funzionalità principali già utilizzabili, possiede delle interfacce semi-definitive e potrebbe mancare di alcune funzionalità sociali e di connettività; durante la versione Alfa si potrebbero verificare dei crash che sono ancora accettabili. La versione Beta dovrebbe essere il nostro software praticamente definito, magari ancora mancante di elementi decorativi, come la schermata iniziale di caricamento e qualche dettaglio di interfaccia, ma dovrebbe essere praticamente identica alla versione 1.0 che andrete a caricare sugli store.

Nel caso in cui la vostra applicazione sia realmente innovativa e abbia tempi di sviluppo relativamente brevi, vi consiglio di mantenere la fase di test Alfa circoscritta a un gruppo di persone con un legame personale stretto e molto forte, questo per evitare di diffondere troppo presto l’idea e correre il rischio di farsela copiare ancora in fase di sviluppo. Una volta raggiunta la versione Beta, potrete coinvolgere un gruppo più ampio di tester. Nel caso in cui, invece, la vostra app andrà a competere in un settore dove sono già presenti alcuni concorrenti e lo sviluppo richieda dei tempi medio-lunghi (per esempio lo sviluppo di un nuovo gioco di strategia), potrete coinvolgere un gruppo più ampio di persone per i test di usabilità (e giocabilità nel nostro esempio) già per la versione Alfa del nostro software.

La selezione di coloro che testano la vostra app è molto importante; in primo luogo dovete trovare l’audience che avete in mente per la vostra app: è perfettamente inutile fare testare l’app di crescita di un neonato al vostro cuginetto di dodici anni, ma la nonna invece ci può essere utile… Il cuginetto lo terremo per la prossima app game che abbiamo in programma. Selezionare l’audience di riferimento è di fondamentale importanza per ottenere dei riscontri utili da parte dei reali utilizzatori della nostra applicazione.

Per comprendere meglio la scelta degli Alfa e Beta tester ho schematizzato il tutto creando le due piramidi delle Figure 5.19 e 5.20.

Proprio per il fatto che l’utente deciderà sempre se rimanere in comunicazione con la vostra app, e in un certo qual modo con gli sviluppatori stessi, anche mentre non sta usando l’app, è importante gestire il timing delle vostre notifiche. Non sommergete i vostri utenti con push continui perché li disattiveranno immediatamente, a meno che non siano essenziali, e perché potrebbero anche cancellare la vostra applicazione, in quanto troppo “intrusiva”.

La sommità di entrambe le piramidi è costituita dal team di sviluppo dell’applicazione: i primi utilizzatori dell’app che state sviluppando siete voi stessi!

Figura 5.19 – La piramide della fase Alfa dei test di usabilità.

Figura 5.20 – La piramide della fase Beta dei test di usabilità.

Si racconta che Steve Jobs utilizzò per mesi le interfacce e l’ergonomia e il design dell’iPhone, testando a fondo ogni minimo particolare; la stessa identica cosa venne fatta, sembra, anche da Larry Page[46] prima del lancio del primo smartphone marchiato Google.

Coinvolgere il gruppo di sviluppo nei test di usabilità non dovrebbe essere molto difficile, ma se siete solo il committente dell’app vi consiglio di chiedere fin dall’inizio quanti saranno i tester del gruppo di sviluppo e di essere coinvolti da subito anche voi stessi nel provare l’app in fase estremamente critica. Chiunque realizzi app lavora tantissimo con simulatori desktop dei device mobili: dei software che simulano su desktop gli effetti mobile, dove il clic del mouse sostituisce il tap del dito. Questo modo di lavorare va benissimo, in quanto rende molto più veloce e agevole lo sviluppo, ma alla fine di ogni fase, o semplicemente alla fine di ogni giornata di lavoro e soprattutto il venerdì pomeriggio, dovrebbe essere creata una versione Alfa dell’app aggiornata con gli ultimi sviluppi e tutto il gruppo di lavoro dovrebbe caricarla sui propri dispositivi per utilizzarla direttamente sui device. La raggiungibilità dei pulsanti, l’usabilità e la chiarezza delle interfacce e i reali vantaggi nell’utilizzo di un’app si possono apprezzare e si devono provare solo se usati nel loro contesto: direttamente su smartphone e su tablet; per questo sono sempre scettico quando conosco sviluppatori e ideatori di app che non possiedono nemmeno uno smartphone. Fortunatamente sono sempre di meno, ma in passato mi è successo di parlare con un esperto di interfacce mobile che possedeva un vecchissimo (e indistruttibile) Nokia. Il vertice della piramide, il primo gruppo dei tester, presenta quindi il vantaggio di una selezione semplice di questi soggetti, visto che sono gli stessi che stanno sviluppando l’app, mantenendo elevato il livello di riservatezza dello sviluppo. Lo svantaggio maggiore di questo gruppo è purtroppo enorme, soprattutto nella fase Beta del progetto: il team di sviluppo conosce già l’applicazione e questo elemento rende “deviati” tutti i loro test, soprattutto per quanto concerne l’utilizzo e l’accessibilità delle funzioni della vostra app. Chi realizza il software sa già che cosa fa, come lo fa e in quale modo: la vostra app è un po’ come la vostra casa, sapete già come sono disposte le stanze, dove si trovano gli interruttori delle luci, il contenuto (quasi sempre) di ogni cassetto e così via; la stessa cosa avviene per l’app che avete realizzato: sapete quali sono tutte le funzionalità e come vi si accede, conoscete come interagire con le vostre interfacce e sapete sempre che cosa succederà dopo aver eseguito una determinata azione. Per questi motivi il team di sviluppo è un’ottima risorsa soprattutto nei primissimi test del progetto, ma sempre meno utile mano a mano che ci si avvicina alla versione Beta del software.

Il secondo gruppo della piramide dei tester è costituito da una cerchia fidata e ristretta di parenti, colleghi e amici di fiducia. Questo insieme di persone è un ottimo gruppo da utilizzare per i test delle vostre app, anche se non perfettamente in target con la vostra audience. I vantaggi sono quelli di un reclutamento semplice e rapido, di un buon livello di riservatezza e soprattutto di un’elevata “indipendenza” rispetto alla vostra applicazione: questo insieme di tester non conosce, perlomeno nei dettagli, la vostra app, non sa come accedere alle sue funzionalità né come usarle. Otterrete degli ottimi riscontri sia in termini di idee sia di usabilità e accessibilità: tenetele tutte nella massima considerazione. Per le app settoriali, anche in questo caso potreste non avere una grande coincidenza tra questo gruppo di tester e l’audience di riferimento del vostro progetto. Questo gruppo può essere coinvolto fin dalla versione Alfa del progetto e risulterà molto utile per testare l’accesso e l’interazione con le funzioni essenziali della vostra app. Risulta fondamentale non fornire nessuna informazione prima del test: non dovete spiegare che cosa fa e come lo fa, se non con qualche parola descrittiva, ancora meglio un testo di una riga per mail e niente più, perché se doveste fornire in anticipo alcune informazioni rischiereste di “deviare” statisticamente anche questo gruppo di tester.

Il terzo gruppo della piramide dei tester è costituito da professionisti e leader/influencer di settore, nel caso in cui la nostra applicazione si rivolga a una determinata nicchia di utenti: l’app per il tracking della mia giornata di sci dovrebbe avere come tester, oltre ad altri sviluppatori di app (preferibilmente con esperienze in tracking app), anche sciatori, escursionisti, amici dello sci, soggetti che gestiscono pagine Facebook delle Dolomiti e persone che twittano e mettono su Instagram foto di montagne innevate ogni weekend. Questo gruppo di tester va coinvolto solo nella versione Beta del progetto e, oltre a fornire le migliori indicazioni di usabilità e di test in senso stretto delle funzionalità della vostra applicazione, contribuiranno spesso anche offline alla diffusione e al marketing virale della vostra idea: coinvolgete ancor prima del lancio dell’app i leader e gli influencer di una determinata nicchia di mercato, lavorando insieme sulla stessa passione. Sostanzialmente, appassionando i leader di nicchia, potrete spesso ottenere quella spinta iniziale del tutto spontanea e naturale che spesso fa la differenza nel mondo delle applicazioni.

Non dovete credere che chiunque sviluppi app come voi sia un concorrente, anzi, può essere una risorsa collaborativa enorme; per questo vi consiglio di coinvolgere professionisti che conoscete personalmente e vedrete che vi daranno consigli preziosi e sempre gratuiti. Per lo meno la mia esperienza di tanti anni nel mondo del digitale mi ha insegnato quanto sia utile e quanto arricchisca la collaborazione con altre realtà e altri professionisti dello stesso settore. Lo svantaggio di questo gruppo di tester è la ricerca, la selezione e il loro coinvolgimento nella fase Beta del progetto; per questo motivo dovete “coccolare” al massimo questa stretta cerchia di persone, perché sarà molto utile anche al momento del lancio dell’app e per tutti gli aggiornamenti più importanti e gli sviluppi futuri del progetto: una volta trovati e coinvolti non ne dovete perdere nemmeno uno.

Il quarto gruppo di tester è costituito da un numero più ampio di soggetti, selezionati in linea con l’audience di riferimento, ma non leader di quella nicchia. Questo gruppo dovrebbe essere quello numericamente più ampio e spesso viene trascurato per i “costi” di selezione e gestione. Inoltre, è l’insieme di persone col quale avete un livello di fiducia e riservatezza più basso di tutti e dovete quindi coinvolgerlo solo in fase di prelancio della vostra app, nella fase finale di sviluppo della stessa, ma pronti e disponibili ad accogliere suggerimenti e migliorie dell’ultimo minuto. Questo gruppo di persone, se coinvolto correttamente e appena prima del lancio, potrà contribuire anch’esso al marketing virale dell’applicazione e alla sua diffusione iniziale. Fate sentire i tester come utenti privilegiati e coinvolgeteli quanto più possibile nell’utilizzo della vostra app, rendendoli partecipi delle eventuali migliorie, ringraziando gli utenti più attivi nei credit dell’applicazione e aggiornandoli sullo stato del progetto.

La gestione dei quattro gruppi di tester dovrebbe essere fatta attraverso l’utilizzo di un semplice database o, nei casi minori, perlomeno utilizzando uno o più file .xls. Dovete dividere nei differenti gruppi di utenti i soggetti coinvolti e costruire delle tabelle contenenti i seguenti campi:

Nome del tester: il nome (e cognome) se possibile del soggetto coinvolto.

Dispositivo: tipologia, marca, modello e sistema operativo del dispositivo usato dal soggetto coinvolto per il test. Nel caso in cui il tester possieda più di un dispositivo potete scegliere se duplicare o meno il soggetto per i vari dispositivi oppure coinvolgerlo solo per uno dei device posseduti.

Identifcativo univoco del dispositivo: elemento necessario per i device Apple ai fni della distribuzione dell’app in fase Alfa e Beta: il famoso UDID.

Mail: l’indirizzo di posta elettronica del tester, fondamentale per gestire tutta la comunicazione automatizzata e non con la persona.

Dati socio-demografci (opzionali): per una migliore validità del test dovreste, ove possibile, ottenere almeno le informazioni basilari socio-demografche del soggetto, come il sesso, la fascia di età, la residenza e così via. Questo vi permetterà una migliore distribuzione statistica della vostra app e la possibilità di segmentare tutto il test di usabilità con queste informazioni socio-demografche. Se tutti gli over 45 riscontrano lo stesso problema, mentre gli under 45 lo segnalano sporadicamente, conviene indagare le motivazioni di questa differente percezione della vostra app.

Gestire tutti questi dati e informazioni in database (e in modo praticamente simile in file .xls) permette in primo luogo la possibilità di riutilizzo dei tester per altri progetti. Mano a mano che seleziono i soggetti dei test riduco drasticamente i tempi e i costi per la selezione successiva, inoltre instauro un rapporto di fidelizzazione e coinvolgimento continuativo con altri soggetti appassionati di digitale; in sostanza creo un valore continuativo per l’organizzazione con la quale lavoro. Avere tutto in database permette di ridurre notevolmente i costi di gestione attraverso l’utilizzo di invii automatizzati ai vari gruppi di utenti, fondamentale per la parte operativa dei test.

Una volta selezionati i soggetti da coinvolgere nei test di usabilità nei differenti momenti di sviluppo del software, si può procedere con le fasi esecutive dei test di usabilità che sono molto simili sia in fase Alfa che in fase Beta; il processo dei test è circolare e ripetitivo e dovrebbe compiere almeno due cicli completi.

Le fasi del test essenziali sono: distribuzione, sondaggio, App Analytics, aggiornamento, secondo sondaggio e nuovamente App Analytics.

La fase di distribuzione è quella più tecnica, soprattutto nel complicato sistema di Apple, e consiste nell’invio dell’app, in fase Alfa o Beta, ai tester in modo che possano installarla sul loro dispositivo. Non mi dilungherò nella descrizione di come creare file e distribuzione: tutte queste informazioni sono ampiamente disponibili nei manuali delle diverse piattaforme dei sistemi operativi coi quali si sviluppa.

La fase del sondaggio di usabilità è molto importante: in fase Alfa è possibile eseguire e sentire i riscontri degli utenti anche personalmente, ma in fase Beta l’utilizzo dei sondaggi diventa essenziale sia perché il numero dei soggetti coinvolti è più ampio, ma soprattutto per poter aggregare i dati e segmentarli a piacere. Il sondaggio di usabilità dovrebbe essere fatto direttamente online, dopo un numero congruo di giorni dalla fase di distribuzione e non dovrebbe impegnare il tester per oltre cinque minuti, al massimo dieci; l’utilizzo dei sondaggi direttamente online permette costi molto bassi sia in fase di somministrazione, sia in fase di elaborazione finale delle risposte e per la loro analisi. Lasciate sempre almeno un paio di domande aperte nel sondaggio, in modo che gli utenti vi possano scrivere liberamente e comunicare informazioni e suggerimenti ai quali non avevate nemmeno pensato. È meglio leggere cento commenti di utilizzatori prima di lanciare la vostra app che non doverli leggere direttamente sullo store sotto forma di recensioni… magari non troppo lusinghiere. Il sondaggio vi fornirà tutta una serie di informazioni e dati qualitativi inestimabili e fondamentali per creare un’app di successo.

La fase dell’App Analytics permette di ottenere preziosi dati quantitativi sull’utilizzo della vostra applicazione da parte dei tester. Dovete implementare un software di Analytics già in questa fase, per comprendere subito come gli utenti utilizzeranno realmente la vostra app. Attraverso i dati dell’App Analytics, in questo momento è possibile anche comprendere quanto sia stata realmente testata la vostra applicazione dai soggetti tester e ritenere quindi più o meno attendibili i riscontri del sondaggio.

La fase dell’aggiornamento è spesso difficile da accettare; ma quando si pensa che sia tutto pronto per l’upload, si può scoprire che molti utenti faticano a utilizzare una funzione essenziale della nostra applicazione. Bisogna mantenere la calma in queste situazioni, ma nel caso si riscontri in modo statisticamente rilevante, potrebbe essere necessario anche un forte aggiornamento della nostra app. Meglio farlo in questo momento, ancora al riparo dal pubblico ludibrio delle recensioni negli store, che non doverlo fare quando siamo già presenti nei canali distributivi. La maggior parte delle volte gli aggiustamenti finali saranno minimali, ma estremamente utili al successo dell’app. Implementate le migliorie suggerite o perlomeno rendetele opzionali. I vostri tester ne saranno contenti e si sentiranno realmente coinvolti e attivamente partecipi al vostro progetto. Spesso le persone chiedono solo questo. Una volta apportate tutte le modifiche dovrete chiaramente ridistribuire la versione della vostra app ai tester.

La fase del secondo sondaggio dovrà essere molto snella e veloce, pochissime domande concentrate sulle modifiche apportate e le differenze rispetto alla versione precedente. Nel caso di migliorie minimali, focalizzate la vostra attenzione per vedere se sono cambiate alcune percezioni degli utenti che a questo punto avranno testato più volte la vostra applicazione.

La fase dell’Analytics deve concentrare la propria analisi sulle modifiche dei dati di utilizzo rispetto alla versione precedente: è cambiato qualcosa in termini di durata di utilizzo della nostra app con le modifiche apportate? Ora i tester usano più spesso una determinata funzione dell’app dopo che l’abbiamo resa più evidente all’interno delle nostre interfacce? Oltre a queste domande i dati dell’Analytics vi potranno fornire alcune informazioni nascoste e molto utili già in questa fase soprattutto per il terzo e quarto gruppo di tester, cioè per progetti relativi a audience e nicchie ben specifiche e in fase di pre-lancio. I dati dell’App Analytics vi diranno se i vostri tester continuano a provare (quindi anche a usare) la vostra applicazione in modo continuativo, proprio perché la ritengono utile e rispondente a una reale esigenza. Se notate un utilizzo continuativo e non in seguito a sollecitazioni di sondaggi e aggiornamenti, questo significa che siete sulla strada giusta: è uno dei segnali più incoraggianti, e silenziosi, del successo o meno del vostro progetto.

Concludendo, non sottovalutate mai la forza dei test di usabilità, cercate di restare calmi e non lasciatevi guidare dall’entusiasmo immediato, curate i dettagli e siate pronti ad accogliere e ad ascoltare ogni suggerimento da chiunque, non sottovalutate la voce di nessun tester e non fatevi condurre dalla fretta, soprattutto per i vostri progetti più unici e innovativi, anche se sono mesi che ci lavorate e siete ormai all’arrivo. Tuttavia, uploadare il progetto della vostra vita senza alcuna fase di test strutturata sarebbe come decidere di sposarsi a Las Vegas in una notte da leoni, ma spesso i matrimoni così finiscono dopo pochissimo tempo.

45. Provate a cercare su Google “sketches for nome modello di dispositivo mobile”. Tra i siti migliori segnalo: www.speckyboy.com.

46. Insieme a Sergei Brin, Larry Page è uno dei due fondatori di Google e attualmente è anche l’amministratore delegato della multinazionale americana.

CAPITOLO 6

GUADAGNARE CON LE APPLICAZIONI

Tipologie di remunerazione e numeri del mercato attuale

Non si guadagnano soldi solo vendendo applicazioni. Chiaramente questa rimane una delle fonti di reddito primarie e più intuitive (e scontate) per gli sviluppatori, ma il digitale, si sa, permette modelli di business alternativi rispetto all’ambiente analogico. L’analisi e la conoscenza di queste modalità per generare reddito devono essere ben presenti a ogni sviluppatore e a chiunque abbia una idea di creare un’app.

Esistono sostanzialmente due “macro modalità” relative ai vostri modelli di business che hanno un focus distinto.

1.La prima macro modalità ha come scopo la vendita vera e propria dell’applicazione, quindi l’obiettivo primario da raggiungere a tutti i costi è di vendere l’app attraverso gli store e incassare denaro direttamente dagli utilizzatori fnali dell’applicazione. L’idea viene pensata e sviluppata come un vero e proprio software a sé stante, che risolva effettivamente dei bisogni richiesti dal consumatore. L’applicazione risulta talmente unica e di valore che possiamo realisticamente credere che ci sia un certo numero di persone disposto a pagare questo software.

2.La seconda “macro modalità” ha invece come obiettivo primario quello di ottenere un’audience di utilizzatori la più ampia possibile; per il raggiungimento di questo obiettivo, l’app verrà regalata gratuitamente agli utilizzatori per sfruttare al massimo il potenziale di utenti smartphone e tablet dei vari store. L’idea non deve essere necessariamente unica, il suo contenuto preferibilmente sì, ma deve comunque soddisfare dei bisogni per conquistare il più possibile le persone. In questo gruppo inseriamo inoltre le app sviluppate dalle aziende come strumento di lavoro per i propri dipendenti e collaboratori; in questo caso vi è un’esigenza specifca da parte di un’azienda o di un’organizzazione, che viene risolta attraverso lo sviluppo di un’app. Alcune compagnie aeree hanno per esempio sostituito il contapersone meccanico in dotazione agli steward e alle hostess di bordo con una semplice app aziendale, che svolge la stessa funzione su uno qualsiasi dei dispositivi mobili dei tre principali sistemi operativi. Hanno così ottenuto un’app molto semplice e realizzata in pochissimo tempo, con una minima diminuzione di costi, di trasporto e di logistica correlati ai contapersone.

Ci troviamo di fronte ai seguenti e distinti modelli di business:

1.Macro modalità: Vendita

•1.A. Applicazioni in vendita (tout court).

•1.B. App lite: Applicazioni gratuite limitate; queste app, con l’avvento dell’inapp purchase, sono praticamente in via di estinzione.

•1.C. Applicazioni gratuite con possibilità di in-app purchase della versione Full/Premium e di feature varie aggiuntive.

2.Macro modalità: Audience

•2.A. Applicazioni gratuite con modello di business “a monte”.

•2.B. Applicazioni aziendali in ambito B2B.

•3.B. Applicazioni gratuite sinergiche per la comunicazione di marchi offine e online.

•4.B. Applicazioni gratuite per la creazione di audience pura.

•5.B. Applicazioni gratuite con sistemi di revenue pubblicitaria.

Quando parliamo dei dati degli app store, tutti i numeri di fatturato e i milioni di dollari pagati agli sviluppatori si riferiscono esclusivamente alla prima macro modalità, in quanto è impossibile ottenere tutte le informazioni da tutti i soggetti coinvolti nella seconda modalità di business, che risulta essere anche maggiore rispetto alle vendite dirette; questo a sottolineare quanto ampio e profittevole sia il nuovo mercato digitale in senso allargato.

Vediamo quindi alcuni numeri degli app store riferiti alle prime tipologie di modello di business. La tendenza del mercato indica un consumo sempre maggiore di acquisti e di fatturato generato dai negozi di applicazioni dove, per il momento, i player sostanzialmente coincidono con i rispettivi sistemi operativi e le relative quote di mercato, anche se con alcune eccezioni molto importanti da tenere in considerazione. Attualmente il settore si è concentrato intorno a due player principali: Apple con il suo Apple App Store e Google con il suo Google Play. Inoltre i dati si riferiscono spesso a quanto lo store ha pagato agli sviluppatori e quindi al netto della commissione sulla vendita che trattiene il negozio stesso. Il mercato ha numeri ancora maggiori: le quote che vengono trattenute variano leggermente da app store ad app store anche a seconda del mercato di vendita del prodotto stesso, e variano dal 20 al 30% circa del prezzo di vendita dell’applicazione e/o dell’acquisto in modalità in-app purchase.

Gli ultimi dati disponibili di questi soggetti e i loro tassi di crescita nel corso degli ultimi anni rendono bene l’idea del mercato attuale e potenziale degli smartphone e dei tablet.

Tabella 6.1 – Dati di vendita cumulati dal 2010 (incluso in-app purchase) dei due principali app store mondiali.

Figura 6.1 – Andamento e confronto dati di vendita dei due principali store in miliardi di dollari.

È interessante notare come gli utenti Apple, pur rimanendo sempre in minoranza rispetto a quelli Android, ma aumentando sempre in termini assoluti, restino dei forti compratori di applicazioni rispetto agli utenti Android, che presentano uno scontrino medio più basso rispetto a quelli della mela morsicata. Questo principalmente per tre motivi: in primo luogo gli utenti Apple percepiscono in media un reddito maggiore rispetto alla media degli utenti Android; questa prima “scrematura” è originata alla fonte dal prezzo mediamente più elevato di un dispositivo con il sistema operativo di Google a confronto del mondo Apple. Chiaramente, questo ragionamento cade se la comparazione viene fatta tra utenti Apple e Android con dispositivi di punta, come i modelli più avanzati di Samsung: a prezzi simili dell’hardware corrispondono mediamente congrui utilizzatori, per reddito e spesa, sugli app store. Un secondo motivo è legato alla storicità degli utenti della casa di Cupertino rispetto a quelli di Android. I primi sono utilizzatori che acquistano da molto tempo applicazioni, e prima ancora musica su iTunes; sono consumatori digitali abituati a pagare per il software e per il diritto d’autore; sono soggetti con un’ottima fiducia relativamente alla sicurezza dello store; sono utenti spesso esperti e più predisposti all’acquisto online e con carta di credito. Il terzo principale motivo è legato all’ecosistema dei due negozi: Apple cerca di acquisire l’utente fin dall’inizio. In fase di attivazione del device la casa di Cupertino cerca di ottenere il numero di carta di credito dell’utente. In modo automatico siete catapultati (anche a forza) nel mondo iTunes: il software dello store è lo stesso della sincronizzazione del vostro telefono, del backup dei dati, del trasferimento dei file. Il negozio della mela è sempre lì, a portata di un clic e, una volta che avete inserito la vostra carta di credito, non serviranno più quei dati: sarà sufficiente inserire la password del vostro account… et voilà, avete appena speso 99 centesimi per la vostra app di ricette di torte di frumento. Il fatto di non costringere ogni volta il consumatore a estrarre il portafoglio cercando la carta di credito per inserire numero, scadenza e CVV rende l’acquisto delle applicazioni molto immediato e tutto ciò, unito spesso a prezzi inferiori a un caffè e quasi sempre a una colazione in autogrill, favorisce enormemente l’acquisto immediato ed emotivo, pur non essendo tutto ciò così emotivo come si potrebbe pensare.

La situazione del mercato degli store è comunque in forte e continua evoluzione e questa fotografia del settore potrebbe cambiare completamente nel giro di pochi anni: gli altri soggetti che dispongono di un proprio sistema operativo mobile attualmente occupano posizioni molto distanziate, situazione che ricalca sostanzialmente le rispettive quote di mercato di utilizzo dei device. Alcuni soggetti indipendenti rispetto ai sistemi operativi si ritagliano uno spazio di nicchia, oppure sono in attesa di un ingresso in grande stile, come sembra stiano progettando colossi del calibro di Facebook e Samsung. Stiamo a vedere: non riteniamo che la situazione sia già matura e “fossilizzata”. La guerra degli app store è solo all’inizio.

Applicazioni in vendita (tout court)

Questo è il modello di business alle origini della nascita dei negozi di applicazioni. All’inizio si progettavano e sviluppavano app per poterle vendere al maggior numero di utenti possibili e ottenere quindi i guadagni risultanti dalla formula semplicissima: Fatturato app = Numero di Download x Prezzo di Vendita (al netto delle commissioni dello store). Una formula semplice e ormai conosciuta e perseguita per decenni da chiunque sviluppi un software tradizionale in qualsiasi settore, particolarmente seguita in ambiente video ludico: i creatori dei videogiochi hanno (o avevano, come vedremo in seguito) come obiettivo lo sviluppo di un videogame per venderlo ai giocatori, preferibilmente in tutto il mondo. Le case di sviluppo dei videogame avevano già compreso da tempo la possibilità della vendita diretta del loro prodotto con dei vantaggi enormi: distribuire direttamente e digitalmente un prodotto (il cosiddetto e-commerce diretto) azzera quasi completamente i costi di distribuzione, permettendo di concentrare i propri sforzi e investimenti sul core business. L’acquisto di un’app permette di evitare la stampa sul supporto digitale (cd, dvd, blu-ray ecc.) e tutti i costi di realizzazione del packaging (stampa del manuale, degli imballaggi ecc.). Questa nuova modalità di vendita del software comprime drasticamente i costi di distribuzione, eliminando in toto la logistica: lo sviluppatore ha un solo e unico intermediario tra sé e il consumatore, il negozio di distribuzione dell’app, contrariamente a quanto avveniva in passato con esportatori, importatori, distributori, GDO ecc., ognuno dei quali voleva giustamente essere ricompensato per il proprio lavoro a discapito del valore di creazione del prodotto stesso. Con la vendita quasi diretta di un prodotto digitale ai consumatori, il prezzo viene concentrato sul software poiché normalmente il 70% e oltre di quanto pagato dall’utilizzatore finale per un prodotto finisce direttamente all’azienda che ha realmente realizzato il prodotto stesso.

Questo modello distributivo del software era già presente e utilizzato in modo massivo da anni nel mondo dei videogiochi: la Valve[47], casa di sviluppo di videogame di successo, possiede da anni un proprio canale di acquisto dei giochi con download e attivazione diretta, aggiornamenti e così via, il tutto insieme al multiplayer, denominato Steam, sostanzialmente un iTunes focalizzato sui propri prodotti.

Figura 6.2 – Lo Steam della Valve, uno dei primissimi app store, creato ben prima dell’avvento dei dispositivi mobili per la distribuzione di software, principalmente giochi, e come piattaforma per il multiplayer.

Altri esempi, sempre video ludici, erano i massive multiplayer game, dove il software veniva venduto sotto forma di abbonamento mensile: esempi passati ormai alla storia sono la saga di Ultima Online[48] e World of Warcraft[49].

Figura 6.3 – Immagini da mondi paralleli: Ultima Online e World of Warcraft.

La disintermediazione su scala internazionale di tutto il mercato del software di tipo consumer, in particolare video ludico, generata dalla nascita degli app store e dal numero potenziale di acquirenti, ha provocato un abbattimento enorme delle barriere di ingresso in questi mercati permettendo la nascita di centinaia di piccole e medie aziende dedite allo sviluppo di software in modo indipendente, sempre alla ricerca dell’app perfetta, un po’ come i cercatori d’oro sempre alla ricerca della pepita più grande del mondo.

Questa dinamica molto vantaggiosa e teoricamente abbastanza equa per gli sviluppatori ha innescato, per contro, una lotta al ribasso dei prezzi del software e alla duplicazione (oserei dire esponenziale per alcune categorie e tipologie) di prodotti molto simili tra loro e ripetitivi o costruiti in serie, adattando lo stesso concept a differenti categorie e bisogni. La guerra all’abbassamento dei prezzi di vendita della singola app è una tendenza che stava ormai appiattendo il mercato della vendita diretta: il consumatore voleva pagare sempre meno ottenendo prodotti a bassissimo costo, ma anche con una qualità alquanto ridotta. Gli sviluppatori si sono orientati così sempre di più in una prima fase nel creare le cosiddette “app lite” e attualmente stanno focalizzando i loro maggiori sforzi di generazione di fatturato con la vendita durante l’utilizzo dell’applicazione, ovvero il cosiddetto in-app purchase. Questo avviene soprattutto quando si possiede un prodotto di qualità superiore alla media del mercato: anziché competere abbassando al minimo il prezzo di vendita della mia app, permetto di provarla limitatamente, in modo che il consumatore possa decidere poi se acquistarla o meno pagando un prezzo corretto e pensato dallo sviluppatore in relazione al valore reale del proprio software.

Il modello di business della vendita diretta è quindi in lento declino e sempre meno perseguito dagli sviluppatori, in particolare da quei developer che non hanno creato ancora un’app di successo e non possiedono un marchio storico. Ritengo corretto, in questi casi, provare a pensare se possono esistere, tra gli scenari proposti, altri modelli di business leggermente alternativi alla vendita tout court da valutare in modo molto attento.

La vendita tout court rimane comunque un ottimo modello di business per chi ha un’idea realmente unica, ma anche per coloro che lavorano in campi estremamente specialistici e spesso B2B.

È il caso di Mobile Cam Viewer della mobiDEOS Inc., venduta a 349,99 dollari, dedicata a chi si occupa di sicurezza a livello professionale, che permette, chiaramente in modo completamente criptato, di controllare qualsiasi dispositivo ip-based dal proprio dispositivo mobile come telecamere, sensori ecc.

Figura 6.4 – L’app di mobiDEOS Inc. Mobile Cam Viewer in vendita a 319,99 euro.

Oppure è il caso di Alpha-Trader, che è una vera e propria suite software di investimento globale; dovete però investire 999,99 dollari per poter avere l’app con tutte le quotazioni in tempo reale, alert, push, indicatori e grafici di analisi di qualsiasi genere.

Figura 6.5 – L’app Alpha Trader, completa suite per investimenti azionari e di ogni genere su qualsiasi mercato in vendita a 899,99 euro.

Inoltre, questo primo modello di business si adatta molto alle aziende che hanno già avuto successo nel mondo delle applicazioni o possiedono un marchio riconosciuto da anni nel loro settore di sviluppo di software, in particolare in ambiente video ludico: tutti i sequel di Angry Birds e gli altri giochi sviluppati dalla Rovio Mobile hanno un vantaggio enorme rispetto alla prima versione di successo: possono contare su un numero di utenti ormai fidelizzati e affezionati ai simpatici animaletti volanti.

Figura 6.6 – Angry Birds Star Wars II. Tutti i sequel dell’app della Rovio Mobile hanno ormai un vantaggio enorme in termini di lancio grazie al primo successo ottenuto.

Lo stesso discorso vale per marchi come la Electronic Arts, o titoli come The Sims, e le varie trasposizioni di software già presenti precedentemente su pc e consolle.

Concludendo: criticate al massimo la vostra app e cercate di capire se effettivamente l’utente sia disposto, senza nemmeno provarla, a spendere dei soldi per comprarla “a scatola chiusa”. In caso contrario, o se doveste avere dei dubbi al riguardo, provate a perseguire gli altri modelli di business possibili, puntando principalmente sull’in-app purchase.

Applicazioni gratuite limitate (c.d. app lite), in via di estinzione

Gli sviluppatori si accorsero fin dall’inizio che i negozi di applicazioni venivano inondati di app simili a quelle da loro realizzate o in fase di sviluppo. Una delle prime categorie invase da una moltitudine di app inserite dagli sviluppatori fu certamente quella delle applicazioni di videogiochi. Come fare quindi a fare conoscere e a diffondere il proprio videogame per tablet all’interno di un mare magnum di concorrenti che offrono prodotti simili al nostro? E, soprattutto, come faccio a convincere il consumatore che il mio gioco di automobili sportive (l’ennesimo dello store) vale davvero 2,99 euro perché è fatto graficamente bene, è molto giocabile, divertente e complessivamente molto meglio di tutte le app simili offerte magari a un prezzo inferiore? Si capì immediatamente che per ottenere la vendita non bastavano pochi screenshot, una bella descrizione e una manciata di recensioni positive per fare spendere qualche euro al consumatore di fronte a un’offerta pressoché infinita, soprattutto nelle prime fasi di lancio di un nuovo titolo. Per questo motivo, il modo migliore per dimostrare tutte le qualità della propria applicazione fu quello di farla provare, come avviene da decenni in tantissimi settori.

Figura 6.7 – La stessa applicazione, Angry Birds, proposta in versione completa in vendita e in versione light gratuita.

Ma come far provare un’app in vendita? La comunità degli sviluppatori, come risposta, cominciò fin da subito a realizzare le cosiddette “app lite”, sostanzialmente delle applicazioni pressoché identiche alla versione a pagamento, ma in un qualche modo limitate. Ti faccio provare il mio nuovo videogioco ma puoi fare solo i primi 5 livelli rispetto a tutti quelli inclusi (tecnica utilizzata dalla Rovio per il primo Angry Birds); ti faccio testare il mio gioco di auto fantastico, ma puoi usare solo un circuito, oppure limito il software a livello temporale, permettendo un utilizzo completo per un certo periodo di tempo. Le tipologie di limitazioni delle app lite sono pressoché infinite e dipendono molto anche dalla tipologia di app che sto rendendo disponibile limitatamente e sono state poi trasposte in modo molto spesso simile, se non identico, nel nuovo modello di business dell’in-app purchase.

Queste app lite, che contenevano sempre il nome del videogioco premium a pagamento (per esempio Angry Birds Free e Angry Birds), venivano immesse nell’app store all’interno della stessa categoria dell’applicazione a pagamento e distribuite gratuitamente agli utenti.

L’effetto a catena di questo fenomeno generò un ulteriore aumento esponenziale del numero di app che invasero i negozi. Questa tecnica ha consentito comunque una vendita con una sorta di “prova prima dell’acquisto” per i consumatori, della serie “compro solo ciò che mi piace realmente” e, contemporaneamente, ha permesso a molti sviluppatori di prodotti realmente validi, come la Rovio, di emergere e competere con colossi storici del settore con disponibilità finanziarie e di risorse umane ben più ampie. Vengono davvero premiate l’innovazione e la creatività e il tutto partendo da un’applicazione gratuita di prova del mio prodotto a pagamento.

L’invasione delle app lite, che sono gratuite, anche se non dovrebbero essere realmente considerate tali, oltre a non generare reddito per i negozi di app, duplicavano enormemente i propri cataloghi. Inoltre, gli sviluppatori avevano compreso che era molto più semplice vendere qualcosa a un consumatore dopo averglielo fatto provare e magari anche “a pezzetti” con diverse funzionalità, ma una sola app di prova e una premium non permettevano di frammentare il proprio software in moduli e venderli singolarmente. Nacque così l’operazione win-win per entrambe le parti, cioè la nuova tecnica dell’in-app purchase, che decretò una lenta morte delle app lite e un incremento delle app offerte gratuitamente o, potremmo dire, offerte che sembrano gratuite.

Le app lite sono dei soggetti in via di estinzione, sostituiti da un acquisto in-app molto più flessibile ed evoluto. Forse ne resterà qualche esemplare ma il mio personale consiglio è di perlustrare con attenzione la possibilità dell’in-app purchase prima di perseguire questo arcaico modello di business: non si va alla guerra con un cannone del 1800… almeno non nel 2014.

Applicazioni gratuite con possibilità di in-app purchase della versione Full/Premium e di feature varie

L’in-app purchase ha portato una vera e propria rivoluzione e innovazione dei modelli di business nella vendita delle applicazioni. L’acquisto in-app è la possibilità, da parte dello sviluppatore, di vendere prodotti digitali all’interno dell’app stessa. L’in-app purchase può essere utilizzato sia per app a pagamento, chiedendo ulteriori soldi al nostro consumatore per sbloccare nuove funzionalità di qualsiasi genere, sia per app gratuite ed è proprio per queste ultime che si può ottenere un vero potere esplosivo.

Questa nuova modalità di vendita permette infinite possibilità di limitare la propria versione del software e poi sbloccare tutte le sue funzionalità in modo modulare e personalizzato, a seconda dei desideri dell’utente stesso. Gli sviluppatori inoltre possono progettare in modo completo la propria app, con tutti gli allargamenti dell’idea, implementare i moduli base fondamentali e alcuni moduli che vengono messi a disposizione a pagamento e, analizzando anche la risposta del mercato, decidere di sviluppare anche tutti gli altri moduli e le loro evoluzioni solo in seguito, quando l’app comincia già a incassare soldi. L’in-app purchase modulare permette una sorta di tentativo anche di autofinanziamento da parte di coloro i quali sviluppano e che decidono se investire ulteriore tempo e fatica in un progetto solo se questo sta cominciando a dare i propri frutti e cercano di utilizzare tutte le entrate reinvestendole integralmente negli sviluppi ulteriori.

Tutto ciò permette un’ottima visibilità iniziale, dato che il proprio prodotto viene normalmente distribuito in modo gratuito e poi il cliente inizia a pagare, se vuole la versione completa o sbloccare determinate opzioni. Il fatto di fornire gratuitamente il proprio software, benché più o meno limitato, genera un numero maggiore di download e permette quindi si scalare più velocemente le varie classifiche all’interno dei negozi e ottenere grande visibilità.

Le possibilità di utilizzo dell’in-app purchase sono quindi pressoché infinite, ma possiamo classificare, per ora, i suoi principali usi come segue:

Acquisto della versione completa Premium: l’applicazione è distribuita gratuitamente, ma è limitata secondo i criteri delle app lite. All’interno dell’unica app posso acquistare la versione completa a pagamento. Questo modello di in-app purchase è quello che ha sostituito le app lite permettendo agli sviluppatori di concentrarsi su un’unica versione e di ottenere visibilità e popolarità dell’app che è immediatamente disponibile a un successivo acquisto.

Figura 6.8 – L’app New Star Soccer: nel processo di in-app purchase si può comprare la versione completa del gioco, la licenza pro, a 0,89 euro che elimina anche le pubblicità.

Acquisto modulare di opzioni, funzionalità e prodotti virtuali: all’interno dell’applicazione è presente un vero e proprio negozio di moduli, di opzioni e di veri e propri prodotti digitali che l’utente può acquistare. Questa tipologia e strategia di vendita in-app è utilizzata in moltissimi generi e categorie: funzionalità per migliorare la propria app di gestione delle riunioni, nuovi pacchetti di domande per il vostro quiz preferito, il pallone colorato per le vostre infnite partite di calcio, le armi migliori per colpire i vostri amici in multiplayer. Giochi come Candy Crush Saga[50] o Hay Day[51] (Figure 6.9 e 6.10) hanno fatto storia e guadagnato milioni di dollari (nel momento del suo apice Candy Crush otteneva circa 800.000 dollari al giorno di acquisti in-app) vendendo oggetti virtuali che accelerano e facilitano i due rispettivi giochi. Un cenno a parte va fatto quando uno dei moduli principali, se non praticamente l’unico, è l’eliminazione di messaggi promozionali, che è un modello di business ibrido con quello pubblicitario che vedremo in seguito.

Acquisto di un abbonamento periodico a un servizio: un modello ereditato anch’esso dal mondo dei videogiochi multiplayer di massa. L’utente non compra il gioco vero e proprio, che viene distribuito gratuitamente, ma paga un abbonamento con cadenza periodica per poter giocare. La modalità di sottoscrizione e di pagamento ricorrente si adatta a tantissime tipologie di business e permette un ciclo di vita del cliente molto più lungo e profttevole rispetto alla vendita una tantum. La sottoscrizione genera inoltre una base di utenti, i nostri abbonati, spesso fdelizzata che permette un’offerta e vendita di altri prodotti già sviluppati o che possono essere creati anche in correlazione alla tipologia di utenti che attualmente mi pagano un servizio.

Acquisto di prodotti editoriali: da citare, ma in questo libro non parliamo di prodotti digitali editoriali… ci vorrebbe un e-book a sé stante per questi argomenti.

La tecnica dell’acquisto in-app è stata talmente vantaggiosa e profittevole che in pochissimo tempo ha superato, in termini di fatturato, la vendita diretta di applicazioni. Concludendo, questo modello di business è forse il migliore se siete alla ricerca di guadagno vendendo la vostra app, anche se a moduli o a “pezzettini”. Soprattutto se non avete alle spalle un marchio conosciuto come sviluppatori, se dovete emergere e avete un prodotto unico, la possibilità di distribuire gratuitamente un assaggio (più o meno consistente dipende da voi) della vostra app e renderla popolare è un vantaggio enorme e ultimamente quasi necessario per fare emergere la vostra idea all’interno di un mercato immenso, dove la maggior parte degli utenti non va oltre il cinquantesimo risultato delle ricerche o delle categorie. Per scalare le classifiche avete bisogno di download e di recensioni; per ottenere questo, la spinta iniziale della gratuità del vostro software può giocare un ruolo chiave per tutto il successo del progetto.

Figura 6.9 – Candy Crush Saga genera milioni di dollari vendendo caramelle e leccalecca virtuali che aiutano molto il passaggio di livelli estremamente difficili.

Figura 6.10 – Hay Day fattura decine di migliaia di acquisti di gemme, chiaramente virtuali, che accelerano il gioco e fanno progredire più velocemente tutta la fattoria dell’utente.

I limiti da inserire e le opzioni disponibili in vendita vanno pensate e ragionate con molta attenzione: da un lato non dovete limitare troppo la vostra app per non far perdere la percezione all’utente di quanto sia valida e funzionale e di tutte le cose che può fare, dall’altro lato dovete trovare dei modi per rendere quasi obbligatorio, o perlomeno istintivo, l’acquisto dei vostri moduli e delle vostre opzioni per i reali utilizzatori della vostra applicazione. Dovete trasformare l’utente gratuito in utente a pagamento: con quelli fidelizzati dovrebbe essere automatico, quelli che cancelleranno la vostra app dopo averla provata due volte non sarebbero stati mai comunque dei vostri clienti.

47. La Valve divenne celebre per il videogioco epico Half Life (e i suoi numerosi seguiti), uno sparatutto in prima persona ambientato nel futuro ispirato da un racconto di Stephen King.

48. Ultima Online è un MMORPG (Massive Multiplayer Online Role-Playing Game) sviluppato e aggiornato dal 1997 dalla Origin Systems, in seguito acquisita dalla Electronic Arts Games e fu una delle prime aziende al mondo a sperimentare un vero e proprio sistema di gioco in rete tra utenti reali.

49. World of Warcraft, spesso abbreviato come WoW, è un gioco di ruolo in 3D ambientato nell’universo di Warcraft e suddiviso in quattro continenti principali. I giocatori, provenienti da tutto il mondo, si organizzano tra loro e devono anche collaborare per sconfggere i nemici più potenti in alcune zone dei reami. Il gioco della Blizzard Entertainment ha riscosso un successo planetario e possiede tuttora, dopo anni dalla prima uscita, migliaia di giocatori attivi in tutto il pianeta.

50. Candy Crush Saga: un gioco puzzle in cui si devono combinare almeno 3 caramelle dello stesso colore. Il gioco è a livelli, include mosse speciali (4 o 5 caramelle in fla dello stesso colore) e combinazioni di mosse (caramella a strisce+caramella incarata ecc.). È stata una delle applicazioni più scaricate del 2013.

51. Hay Day: un gioco di strategia in cui bisogna costruire la propria fattoria, coltivare i campi e raccoglierne i prodotti, allevare galline, mucche, pecore, maiali e capre. Si possono anche vendere e comprare le materie prime e i prodotti fniti; gli obiettivi aiutano a salire di livello.

CAPITOLO 7

APP GRATUITE E MODELLI DI BUSINESS

Applicazioni gratuite e possibilità di guadagno

Uno dei tanti insegnamenti che mi diede mia madre fin da quando ero piccolo fu quello che al mondo non ti regala niente nessuno, a meno che non sia qualche parente molto stretto. Questa regola vale anche nel digitale, con alcune rarissime eccezioni, ma la maggior parte delle applicazioni gratuite, ovvero regalate, in realtà possiede un modello di business alternativo oppure, come già visto, risulta limitata in un certo modo e serve per invogliare verso l’acquisto della versione premium o di modalità aggiuntive. La creazione di un modello di business dove solo in apparenza il software viene regalato e risulta free non è un’invenzione degli app store ma esiste, come già accennato, ormai da decenni nel settore dei software. Questo modello di apparente “free”, che nasconde una vendita di un prodotto “premium”, è denominato “freemium”. Dopo aver analizzato questa tipologia di modalità, che resta comunque collegata all’obiettivo finale di vendita del prodotto, passiamo all’analisi di ciò che è realmente e veramente gratuito, perlomeno per il consumatore finale. Anche se, in parte, la vecchia regola di mia madre vale ancora. L’app è un investimento e un costo, non solo in termini di sviluppo, ma anche per il suo mantenimento. Chiunque investa soldi e denaro in questo business richiede in un modo o nell’altro un ritorno economico: gli sviluppatori fanno volontariato in altri settori. Vediamo quindi di comprendere altri modelli di business e chi paga al posto del consumatore o dell’utilizzatore finale (Tabella 7.1).

Cerchiamo ora di chiarire singolarmente questi modelli di business, anche grazie all’utilizzo di casi studio ed esempi reali.

Applicazioni gratuite con modello di business “a monte”

I modelli di business delle applicazioni non terminano quindi solamente con la vendita del prodotto in sé, ma permettono sbocchi in sistemi alternativi per fare impresa molto interessanti e innovativi.

Tabella 7.1 – Modelli di business alternativi a quelli della vendita.

Uno dei primi modelli alternativi è alquanto tradizionale e già molto utilizzato nel settore digitale: il modello di business in cui il fatturato non è generato dalla vendita dell’applicativo verso i suoi utilizzatori, bensì verso un’entità o più entità poste “a monte” nel modello di business che ottengono dei benefici economici dall’utilizzo dell’app e sono quindi disposte a pagare un quid per il fatto di essere presenti all’interno del software in qualche modo.

Per comprendere facilmente questo modello di business pensiamo a una delle applicazioni più famose in ambito di prenotazione alberghiera: Booking.com[52] (Figura 7.1).

Per Booking.com, la propria applicazione è una mera estensione delle attività desktop, ma l’avvento di smartphone e tablet ha reso ancora più performante la sua operatività perché l’utente in mobilità ha una propensione alla conversione molto più alta, per le ragioni già esaminate, rispetto al navigatore desktop. L’app di Booking.com non è una semplice trasposizione del sito desktop su dispositivi mobili, ma un vero e proprio strumento di prenotazione in mobilità estremamente potente. Ma dove guadagna Booking? Dal modello di business ormai consolidato del settore del turismo e degli affiliati al portale: quando un utente prenota via Booking, l’hotel in questione paga all’azienda una percentuale della prenotazione che varia da alcuni punti fino a raggiungere anche quote ragguardevoli del 25% in alcuni casi, tutto ciò senza alcuna maggiorazione di prezzo per l’utente finale, anzi, garantendo spesso il miglior prezzo sul mercato.

Figura 7.1 – L’app di Booking.com è gratuita lato utente, il suo utilizzo non mi costa nulla se non chiaramente al momento della prenotazione; un esempio chiaro e reale di app gratuita con modello business “a monte”.

La sua applicazione, sia per smartphone che per iPad e con due versioni ben distinte per sfruttare al massimo le differenti dimensioni degli schermi e di contesto di utilizzo, ha avuto un enorme successo ed è tra le preferite a livello europeo nel settore turismo fin dal momento del suo lancio. Mantenete sempre distinto comunque Booking come app con modello di business “a monte” e non confondetela con altre applicazioni, sempre del turismo, come quella di SkyScanner[53] che rientra nel modello di business pubblicitario, poiché sposta semplicemente traffico verso diverse agenzie di viaggio online (OTA) e viene ripagato per traffico e conversione generati, sostanzialmente come per la pubblicità a performance.

In questa tipologia di modello di business, la società proprietaria dell’app è un affiliante e concentra spesso il proprio business in un’attività non digitale, ma tradizionale. Compito principale dell’affiliante, come nel caso di Booking.com, non è solo quello di sviluppare un’applicazione funzionale ed efficiente, ma soprattutto di stabilire contratti e accordi di affiliazione con un numero elevato di strutture ricettive, ottenendo percentuali di commissione molto alte e offrendo dei software di gestione agli affiliati in modo che possano gestire la loro parte di business all’affiliante. La potenza di Booking.com non è quindi solo quella di avere un’applicazione molto bella e funzionale, ma di avere anche tantissimi hotel al proprio interno, i prezzi tra i più bassi attualmente sul mercato e un sistema di recensioni chiuso molto più affidabile (ma anche quantitativamente più povero) rispetto ad altri aperti a tutti e non solo a coloro che hanno prenotato (come per esempio TripAdvisor).

Figura 7.2 – Le recensioni degli utenti di TripAdvisor.

Applicazioni aziendali in ambito B2B

Un secondo modello di business realmente gratuito per i propri utilizzatori è quello delle app aziendali in ambito B2B: sostanzialmente le aziende investono del denaro per fornire ai propri dipendenti e collaboratori dei veri e propri strumenti di lavoro. In questo caso l’app viene pagata dal committente come un vero e proprio software e poi viene distribuita gratuitamente all’interno dell’azienda. L’utilizzatore finale non la paga, ma chiaramente la può usare perché l’ha pagata il proprio datore di lavoro. Una delle tipologie di app B2B di maggiore diffusione è quella dei cataloghi digitali per la rete di vendita.

I dispositivi mobili hanno permesso la digitalizzazione e la portabilità massima dell’informazione. Per questo motivo molte aziende stanno utilizzando già da molto tempo, o sono in procinto di farlo con un leggero ritardo, le potenzialità dei tablet come sostituto del vecchio catalogo cartaceo. A differenza di quest’ultimo, un tablet o uno smartphone sono molto meno ingombranti, più leggeri, aggiornabili, multimediali e interattivi. L’innovazione in ambito B2B della forza vendita può essere considerata un caso studio e un tema di ispirazione per la realizzazione di qualsiasi applicazione in ambiente B2B, a patto che si adatti alla propria divisione aziendale e crei un ambiente che migliori e incrementi la produttività. Ogni divisione aziendale scambia e condivide informazioni e potrebbe quindi avere bisogno di strumenti più moderni e rapidi di quanto attualmente dispone.

Vediamo quindi di analizzare e confrontare il vecchio catalogo cartaceo con quello nuovo, strumento ormai comune nelle mani di numerosi agenti.

| Catalogo Cartaceo | Catalogo Digitale*
Portabilità | 1 su 10 | 10 su 10
Usabilità | 5 su 10 | 10 su 10**
Aggiornabilità | 4 su 10 | 10 su 10
Multimedialità | 3 su 10 | 10 su 10
Interattività | 1 su 10 | 10 su 10

* Per app Catalogo si intende un vero e proprio prodotto in digitale, non dei PDF inseriti in un tablet.

** Dipende anche da chi lo utilizza e da chi lo realizza.

Tabella 7.2 – Il vecchio catalogo cartaceo a confronto, attraverso un sistema di voti, con il nuovo catalogo digitale.

Analizziamo, spieghiamo e cerchiamo ispirazione da ogni singolo punto.

Portabilità: alcuni cataloghi avevano (e hanno, per chi ancora non ha digitalizzato) raggiunto delle dimensioni, in termini di ingombro e di pesantezza ai limiti degli sforzi fsici degli stessi agenti. La fatica fsica, che può sembrare inizialmente quasi comica, nel trasportare dei veri e propri faldoni più volte al giorno, spesso in percorsi medio-lunghi (pensiamo solo alla rete di vendita di prodotti ospedalieri) era in realtà un problema ben più serio di quanto si pensi. La digitalizzazione della carta risolve tutte queste problematiche… E lo dico ripensando a “IL Castiglioni Mariotti”, famoso vocabolario “mattone” di italiano-latino… avessi avuto un tablet.

Usabilità: per quanto un agente di vendita sia bravo a utilizzare la carta e il proprio catalogo, non riuscirà mai a essere veloce e produttivo come un bravo utilizzatore dello stesso prodotto in ambito digitale. Pensiamo banalmente alla ricerca di un codice di un articolo del catalogo: con il cartaceo impiego perlomeno alcuni secondi, con il digitale, se sono rapido nella battitura, ci metto un paio di secondi. Inoltre, nel catalogo non dispongo di una vera e propria navigazione incrociata, passo da un articolo all’altro attraverso un codice e un paio di altre informazioni al massimo. Con un catalogo digitale posso scegliere un prodotto e vedere poi qualsiasi altro articolo a catalogo dello stesso colore, oppure dello stesso prezzo: le possibilità di utilizzo e di interazione segmentata dei dati dei prodotti o dei servizi di un catalogo digitale sono pressoché infnite. Il giudizio circa l’usabilità dipende comunque sempre dall’utilizzatore e da coloro che hanno sviluppato il software. È chiaro che devo capire se le mie risorse umane siano o meno pronte per il digitale; molto spesso le aziende che hanno atteso o si stanno approcciando solo adesso alla digitalizzazione non lo hanno fatto prima proprio perché non ritenevano di avere del personale adeguatamente preparato all’utilizzo di questi strumenti. Adesso, però, non è più possibile ritardare se si vuole continuare a competere con chi questi strumenti li utilizza già sul campo; nel caso le risorse umane non siano adeguate e non ancora pronte, bisognerebbe chiedersi in primo luogo perché e soprattutto agire. Di sicuro è molto più semplice di quanto non si possa pensare formare degli individui all’utilizzo di un tablet, soprattutto se questo tablet è rivolto a un’applicazione in particolare, per persone che sono ancora attive nel mondo del lavoro: se ce l’ha fatta mio padre che non aveva mai tenuto in mano il mouse di un computer, ce la possono fare tutti… Scusa papà!

Aggiornabilità: un altro problema enorme del prodotto analogico è la sua aggiornabilità. L’aggiornamento del listino prezzi e del catalogo in generale comportava la stampa di aggiornamenti al catalogo (che diminuivano ulteriormente l’usabilità dello stesso) e, prima o poi per tutti, la ristampa completa del catalogo stesso; tutto ciò con dei costi continuativi aziendali non indifferenti, sia in termini di realizzazione sia in termini di costi di stampa. La digitalizzazione di un catalogo permette un suo aggiornamento in modo rapido, che può essere addirittura automatizzato a livello aziendale. Un’impresa può distribuire via Internet i propri aggiornamenti al catalogo che gli agenti possono installare in modo intuitivo dall’app stessa. Personalmente consiglio che il catalogo risieda offine, in modo che chiunque possa operare a prescindere dalla presenza o meno di connettività; chiaramente nel caso in cui un agente sia online, il catalogo potrebbe offrire funzionalità aggiuntive. Ma l’assenza di Internet non dovrebbe pregiudicare affatto tutte le funzionalità di un catalogo multimediale interattivo, in quanto chi sviluppa l’applicazione può creare un database offine e caricare sul device stesso le informazioni. Una volta raggiunta nuovamente la connettività, il tablet o lo smartphone invieranno online tutti i dati archiviati in locale aggiornando tutto il sistema. Gli aggiornamenti di un catalogo digitale sono quindi a bassissimo costo, rapidi e bidirezionali.

Multimedialità: l’ambiente digitale permette e incoraggia la multimedialità; un catalogo cartaceo non poteva offrire queste caratteristiche, essendo dominato esclusivamente dal testo e dalle immagini. Un catalogo digitale permette infnite possibilità: musica, parlato, video, realtà aumentata, in abbinamento a un cartaceo più snello, sono tutte possibilità alla portata di qualunque tipologia di azienda in questo momento e dovrebbero essere sfruttate molto meglio. L’utilizzo in particolare dei video permette una fruizione molto più interessante e coinvolgente del catalogo, ma anche più informativa: con i video non solo posso esaltare le caratteristiche del prodotto, ma posso anche far vedere sul campo il suo utilizzo e offrire un vero e proprio manuale d’uso in formato video anziché cartaceo (oppure insieme). A molti di voi sarà capitato di montare un mobile Ikea: avere un video sul montaggio anziché il semplice manuale di istruzioni potrebbe aiutarvi molto in fase di montaggio, evitandovi situazioni imbarazzanti, soprattutto per chi il “fai da te” lo fa una volta all’anno.

Interattività: con una pagina cartacea, fno a pochissimo tempo fa, potevo interagire in modo limitatissimo o praticamente nullo. In un catalogo digitale, ma anche nell’utilizzo insieme di carta e digitale, è possibile creare una vera e propria interazione catalogo/fruitori, sia fsica, attraverso l’utilizzo della realtà aumentata, sia in termini informativi. Posso verifcare in tempo reale la disponibilità a magazzino di un prodotto con determinante varianti e la sua esatta ubicazione, posso raccogliere e inviare immediatamente un ordine, ottenere e scansionare frme digitali su contratti digitali. Sostanzialmente, un prodotto digitale permette un dialogo e un’interazione biunivoca tra chi fornisce il catalogo e chi lo sfoglia, sia esso un agente, ma anche un consumatore fnale.

In sintesi, il prodotto digitale sconfigge il prodotto analogico su ogni fronte. Molti penseranno che l’autore sia un detrattore della buona e vecchia carta. Personalmente non credo nell’abbandono totale della cellulosa e penso che sia comunque giusto, e non semplicemente ecologico, cercare di risparmiare montagne di cataloghi inutili e giganteschi e i relativi alberi. Credo che la carta non morirà mai e che sarà sempre presente… ma la carta utile, non quella inutile. Ritengo, inoltre, che la carta non sia più solo carta, ma sia qualcosa di nuovo e tutto questo proprio grazie ai dispositivi mobili.

Figura 7.3 – La realtà aumentata del catalogo Ikea del 2014: l’unione carta, dispositivi mobili e app apre orizzonti ancora largamente inesplorati e molto interessanti.

Un esempio su tutti è l’utilizzo e il connubio tra catalogo cartaceo e digitale realizzato negli ultimi anni da parte di Ikea[54]. In particolare, i cataloghi del 2013 e del 2014 permettono un’interazione tra carta e digitale estremamente interessante. Ikea ha utilizzato la tecnica della realtà aumentata: con la telecamera del dispositivo si può interagire con alcuni prodotti del catalogo semplicemente piazzando la pagina nella stanza e inquadrandola con il device; in questo modo si può visualizzare l’oggetto del catalogo stesso direttamente nell’ambiente e posizionarlo a piacere per vedere come sta e quanto spazio occupa. È inoltre possibile reperire altre informazioni, come video di approfondimento (e video dei montaggi dei mobili stessi), con varianti di colore visualizzabili in tempo reale e amenità varie.

Il caso studio del catalogo e la sua interpretazione in chiave moderna da parte di Ikea dovrebbero fare riflettere chiunque occupi una posizione all’interno di un’organizzazione: come potrei sfruttare il potenziale di tutta la mia carta e il mio ambiente offline attraverso l’utilizzo dei dispositivi mobili? Ricordatevi sempre che l’hardware e il software esistono già e sono già disponibili, mancano solo le idee e le strategie applicative per poterne sfruttare al massimo i vantaggi.

Pensate sempre che i dispositivi mobili sono in primo luogo dispositivi, appunto, e possono essere utilizzati come strumenti. È il caso di molte aziende di logistica, che stanno usando sempre di più i tablet e gli smartphone per scansionare QR Code e codici a barre delle loro spedizioni, ottenere le firme di ricevuta delle consegne, nonché le indicazioni stradali tramite GPS del giro più efficiente che devono compiere per le consegne.

Un altro caso classico è quello di molti bar e ristoranti, dove il cameriere ha sostituito il classico blocchetto per la raccolta dell’ordine con un iPod o uno smartphone. Altri stanno addirittura dotando direttamente i tavoli di dispositivi mobili in modo che gli avventori possano fare l’ordine direttamente, riducendo quindi l’impegno del personale e aumentando contemporaneamente la produttività. Niente di nuovo: tutto ciò ricorda molto il menu delle sagre dove inserisci la quantità nel quadratino vicino alla “salsiccia con polenta”, ma fa molto più digital e “trendy”.

Figura 7.4 – Nuovi modi di ordinare al bar.

Sostanzialmente, prima già vedevate ovunque un palmare in ambito B2B; questo è stato o sarà ben presto sostituito da dispositivi molto più diffusi, flessibili e la cui programmazione risulterà più semplice e dialogherà meglio con tutte le altre unità informative aziendali.

Concludendo: la presenza dei dispositivi mobili offre delle opportunità a tutte le aziende, con barriere di ingresso abbastanza limitate e costi realizzativi in forte diminuzione. Le imprese devono però comprendere appieno le possibilità che hanno e come utilizzare al meglio questi potentissimi strumenti ormai diffusi ovunque. Le imprese che intendono sviluppare un’idea devono affiancare gli sviluppatori stessi per far comprendere loro lo status quo aziendale in termini di che cosa si vuole ottenere attraverso l’app e soprattutto chi saranno gli utilizzatori dell’applicazione stessa. Il team di sviluppo dovrà capire esattamente gli obiettivi e analizzare, insieme al cliente, tutte le possibilità e le varianti che sono attualmente disponibili per raggiungerli. Sarà difficile che un’azienda parli di “database distribuito” e di “aggiornamenti incrementali”, perciò gli sviluppatori devono comprendere le esigenze, offrire vie alternative perseguibili e fornire sempre una panoramica a 360 gradi sulle possibilità esistenti per ottenere i migliori risultati.

Applicazioni gratuite sinergiche per la comunicazione di marchi offline e online

La comunicazione rincorre continuamente l’audience (e anche la pubblicità). Le persone passano sempre più tempo collegate e di fronte a uno schermo mobile, sia esso un tablet o uno smartphone. Per questo motivo diventa ormai fondamentale saper gestire la comunicazione in questo nuovo ambito digitale. Che cosa può fare una azienda per comunicare nel mondo delle applicazioni il proprio marchio? Tantissimo, e le possibilità sono realmente infinite. Una regola fondamentale, come già descritto, è quella di lavorare sulla passione degli utenti piuttosto che direttamente sui propri prodotti e i propri servizi. Le tecniche di inbound marketing sono fondamentali in questo caso: non pensate che, solo per il fatto di non chiedere nulla a un utente, questi apprezzerà automaticamente la vostra applicazione gratuita e si fidelizzerà di più al vostro marchio.

Il vostro utente in realtà paga un prezzo in termini di tempo speso per scaricare e lanciare la vostra app, il tempo preziosissimo della sua vita. Se pensiamo che, poiché è gratis, uno non si lamenterà mai, non abbiamo ancora capito l’umore del digitale: verrete molto probabilmente stroncati da recensioni pessime, soprattutto se il vostro marchio è conosciuto e il consumatore sa che potete investire qualcosina in più nella vostra comunicazione.

Se la vostra app fosse semplicemente il vostro catalogo in PDF, oppure se avesse solo due funzionalità rispetto alla versione desktop che offrite ai vostri clienti, il rischio di venire travolti da un giudizio pessimo è molto alto e, paradossalmente, consiglio di non sviluppare nemmeno quell’applicazione. Dovete rendere l’esperienza in app dei vostri utenti gradevole e piacevole come quella offline o come quella che offrite in modalità desktop. Un esempio molto semplice da comprendere è quello relativo alle app di home banking. Offrire una versione estremamente limitata rispetto a quella del sito web non ottimizzato potrebbe essere un vero e proprio boomerang della comunicazione; piuttosto di un’app semplice e inutile converrebbe che l’istituto bancario migliorasse la propria versione mobile del sito web e dell’home banking tradizionale.

Un caso studio al quale ho contribuito personalmente e attivamente è quello della cioccolata Otto Chocolates. Quest’azienda italiana, nata da pochissimo tempo, presenta due punti di forza fondamentali: il suo cioccolato è biologico e Fairtrade®, con monorigine peruviana. Tutto il cacao organico proviene da una zona ben precisa e attraverso il commercio equo, i coltivatori in Perù ricevono un sovrapprezzo per il loro raccolto per garantire una maggiore distribuzione della ricchezza. Uno dei punti più importanti in termini di comunicazione per Otto Chocolates è quello di spostare l’attenzione del consumatore verso la zona di origine della coltivazione del cacao. Un prodotto alimentare buono e sano deriva in primo luogo dalle materie prime utilizzate e da come queste vengono coltivate oltre che dai metodi di trasformazione. La provenienza e l’origine del cacao, così come la tipologia di frutto utilizzata, sono di fondamentale importanza per la riuscita di un’ottima cioccolata, senza aggiunta di alcun prodotto chimico o altri che esaltino in modo artificiale i sapori. Mentre il consumatore italiano è già attento all’origine dei prodotti alimentari che mangia quotidianamente come uova, formaggio, ma anche per il vino e altri ancora, sembra che di fronte a una tavoletta di cioccolato questo principio venga meno. Forse anche perché ha poca possibilità di scelta, soprattutto se vuole contenere la propria spesa a livelli medi senza spendere un capitale per 100 grammi di cioccolato. La strategia è quella di informare, in tutti i modi possibili, il consumatore, che spesso non conosce nemmeno la forma delle cabosse (il frutto del cacao) e come avviene la sua lavorazione. Per questo motivo è stata realizzata un’applicazione di tipo videogioco strategico dove l’utente deve partire da un piccolo villaggio di coltivatori e cominciare tutta la filiera del cioccolato, venendo in questo modo a conoscenza, secondo le logiche dell’edutainment, di tutti i processi di lavorazione e delle variabili in gioco. Scopo dell’app è quello di produrre tutte le cinque ricette Otto Chocolates, partendo dalla piantagione e passando per il laboratorio. Altri giochi hanno ispirato quello di OttoChocolate, primi fra tutti l’antichissimo The Settlers, ma anche un poco di Farmville e di Hay Day. Il videogame cerca quindi di insegnare, divertendo, che cosa sta alle spalle di una semplice tavoletta di cioccolato. Infine l’app fa comprendere anche il concetto di Fairtrade® al videogiocatore: per ogni 10 Otto Coins (la moneta utilizzata per comprare e vendere prodotti, piante e macchinari del gioco) ricevuti l’utente guadagna anche un Social Coin: questi ultimi vanno spesi per costruire gli edifici sociali della scuola e dell’ospedale che sono fondamentali per avanzare all’interno del gioco.

Sviluppato principalmente per iPad, e per il momento solo iOS, il gioco ha riscosso fin da subito un notevole successo in Italia, ma, sorprendentemente essendo solo in italiano, anche all’estero con alcune migliaia di download. Cosa ancora più importante è l’engagement degli utenti che, con un livello medio raggiunto di 7 su 20 e un tempo medio di gioco di circa 3 ore e mezza, è stato collegato in modo estremamente intenso a questo nuovo brand sconosciuto (il lancio del prodotto fisico è ancora in atto sul territorio nazionale ed è cominciato nell’ottobre del 2013).

Figura 7.5 – La schermata del gioco di Otto Chocolates (OttoChocolate) della piantagione per la coltivazione del cacao e le sue prime trasformazioni sul campo: fermentazione ed essiccazione.

Figura 7.6 – La schermata del gioco di Otto Chocolates (OttoChocolate) del laboratorio dove le fave di cacao vengono trasformate in dolcissime tavolette di cioccolato. Il brand è sempre sullo sfondo, ma mai invasivo.

Stabilire un contatto così intenso, ma al contempo così “delicato” e poco invasivo nei confronti dei consumatori moderni, è una mossa vincente. Il brand Otto Chocolates è comunque presente sempre in modo molto leggero e il consumatore non ha mai la percezione di un brand ingombrante che cerchi di spostarlo verso l’acquisto del proprio cioccolato. Non è questo l’intento dell’app, bensì quello di informare e far conoscere meglio il mondo del cacao. Una volta che il consumatore è informato, l’acquisto di un cioccolato buono, sano e Fairtrade® è un processo naturale. Il consumatore moderno non vuole essere bombardato di slogan pubblicitari, anzi è saturo di persone che gli chiedono e gli urlano in ogni modo dicendogli quale prodotto comprare. L’acquirente moderno, in modo particolare il leader consumer, è vaccinato al mass marketing tradizionale classico e necessita di qualcosa di nuovo. Se si vuole emergere in mercati maturi, con player che sono multinazionali del calibro di Nestlé, Lindt, Kraft che dispongono di budget smisuratamente più grandi dei vostri, vi dovete inventare delle forme di marketing alternative, meno invasive, ma che, quando vanno a segno, lo fanno profondamente. È un po’ come offrire una sorta di servizio (in questo caso intrattenimento ed educazione) ai propri utenti: così verrete ricordati in modo positivo e a lungo.

Applicazioni gratuite per la creazione di audience pura: l’importanza della base utenti

In alcuni rarissimi casi, l’app offre solo un servizio, senza volere apparentemente nulla in cambio. È il caso di tutti i social network e della loro classica linea di crescita e di sviluppo. Pensiamo a un caso su tutti: Instagram, un’app social network che permette di scattare, editare e condividere le proprie fotografie. Si possono seguire gli utenti ed essere seguiti. È stata lanciata nel 2010 e acquistata da Facebook nel 2012 per circa 1 miliardo di dollari.

In questo caso però bisogna fare una premessa molto importante: avete bisogno di qualcuno che creda in voi e nel vostro progetto, un business angel, un piccolo fondo di investimento, un gruppo di persone facoltose a cui piace il progetto. Eviterei di chiedere soldi a familiari e parenti: piuttosto investiteci voi tutto quello che avete. Gli sviluppatori, si sa, non sono dotati di una grande quantità di capitale da investire; sono spesso giovani con tanta energia e una splendida idea, ma pochi soldi nel conto in banca. Prima o poi avrete bisogno di uno o più investitori che credono nel vostro progetto se volete perseguire questo modello di business. Dal punto di vista distributivo e del marketing è semplice: non faccio pagare nulla all’utente e non gli infliggo nemmeno un messaggio pubblicitario, nemmeno in termini di inbound marketing.

Per questo modello di business l’obiettivo fondamentale è quello di accrescere in modo molto rapido e in termini esponenziali la propria audience. Il numero degli utenti che utilizzano questo tipo di applicazioni è di fondamentale importanza per la sopravvivenza stessa dell’app e per poter raggiungere l’obiettivo primario fondamentale: farsi comprare da un grosso player o arrivare addirittura a quotarsi in qualche mercato azionario tecnologico. Tutti i social network sono nati così: senza pubblicità e gratuiti per tutti. Anche Google stessa nacque in questo modo e l’AdWords fu introdotto solo in seguito: cerco di catturare la massa in modo pulito, senza sponsor, banner e pubblicità vari. Una volta raggiunto il cosiddetto punto di non ritorno, metto in atto tutte le tecniche di advertising che avevo già immaginato. Twitter, YouTube, Pinterest, WhatsApp, e chiunque altro: tutti hanno cominciato senza alcun fatturato, anche per diverso tempo, ma con ingenti costi, poiché quando la massa degli utenti diventa molto ampia, i costi della infrastruttura a livello anche solo semplicemente di server o di banda inizia ad aggirarsi intorno ad alcune centinaia di migliaia di euro. Senza un gruppo di investitori alle spalle è praticamente impossibile sopravvivere. Principalmente per questi motivi finanziari e di investimenti, in Italia, ma in generale anche a livello europeo, è molto più difficile e complesso perseguire questo modello di business per la mancanza di un vero e proprio mercato di investimenti e di fondi di investimento che amino rischiare soprattutto in settori nuovi, in continuo cambiamento. Molto spesso, chi gestisce questi fondi non ha le capacità per giudicare a fondo le probabilità di successo. Motivi principalmente finanziari e di mobilità del capitale hanno fatto sì che tutti i soggetti precedentemente citati siano nati e si siano evoluti negli Stati Uniti d’America, dove il substrato economico e la mentalità finanziaria e imprenditoriale sono molto più propensi a questa tipologia di investimento.

Una volta raggiunta la massa critica di utenti, l’azienda dell’app si quota in Borsa (Twitter) oppure si lascia comprare da un player più importante (Instagram) o prova a restare ancora in attesa aspettando un’ulteriore esplosione per puntare veramente in altro (SnapChat).

Guadagnare con la pubblicità: funzionamento della pubblicità nelle app

Non tutti hanno la fortuna di incontrare investitori che credono nel loro progetto. Tuttavia, anche in questi casi, chi investe vuole un ritorno economico del proprio sforzo finanziario. Prima o poi la pubblicità arriva anche sui social network più puristi, come Instagram. Quindi come funziona la pubblicità nelle applicazioni dal punto di vista di un editore o, più genericamente, di un publisher? Prima di tutto cerchiamo di schematizzare i ruoli e i soggetti della catena pubblicitaria.

La Figura 7.7 rappresenta schematicamente come funziona la catena del valore della pubblicità tradizionale e quali sono i soggetti principali: poiché in questo capitolo stiamo spiegando le possibilità di guadagnare soldi con le applicazioni, cominciamo fin dall’inizio a leggere questa filiera partendo dall’editore.

L’editore è colui che crea il contenuto: un giornale crea contenuto testuale, articoli e notizie, una radio ha un contenuto audio di musica e trasmissioni parlate, la televisione ha le sue trasmissioni televisive.

Figura 7.7 – Modello semplificato della catena pubblicitaria tradizionale: Inserzionista, Agenzia Media, Concessionaria, Editore.

Un editore quindi crea un contenuto, e dove esiste contenuto, in modo più o meno forte e più o meno rapido, arriva anche l’audience: i lettori per i giornali, gli ascoltatori per la la radio e gli spettatori per la televisione. Il marketing e la comunicazione e i loro investimenti sono alla ricerca continua dell’audience e del pubblico in generale. Senza un pubblico il mio messaggio pubblicitario e la mia campagna cadono nel nulla. Al contenuto viene quindi affiancato uno spazio pubblicitario. In Italia (e in altri Paesi europei) l’editore non può vendere direttamente questi spazi pubblicitari, in quanto vietato per legge. Per questo ogni editore si rivolge a una o più concessionarie pubblicitarie, in esclusiva o meno, e affida loro il compito di vendere i propri spazi pubblicitari. La concessionaria incontra quindi le agenzie media che pianificano le campagne degli inserzionisti a seconda dell’audience ricercata.

Nell’ambiente digitale le intermediazioni vengono spesso evitate e si cerca di mettere in contatto domanda e offerta in modo diretto. In tal senso il digitale, Internet per primo in ordine cronologico, sta mettendo in forte difficoltà tutto il gruppo degli intermediari e ciò a discapito dell’intera catena del valore, compresi gli editori che, negli ultimi anni, sono in forte difficoltà nei loro mercati tradizionali.

La catena corta della filiera pubblicitaria online di fatto tende a eliminare uno degli intermediari accorciando tutto il sistema (Figura 7.8). Inoltre, vi è una perdita del controllo da parte degli editori che possono difficilmente decidere che tipo di inserzionisti avere e soprattutto vengono ripagati spesso in base a misurazioni analitiche e addirittura a performance. Un modello verso il quale alcuni editori non erano e non sono ancora pronti, perché abituati a un mercato sempre in crescita e alle “vacche grasse”. Inoltre gli editori tradizionali hanno perso audience non solo in termini assoluti, ma soprattutto come tempo speso dal consumatore medio su quel canale: i telespettatori diminuiscono sempre di più e soprattutto le persone iniziano a guardare di meno la televisione sullo schermo tradizionale, perché probabilmente la guardano sul proprio tablet o sul pc in modalità on-demand. Internet e i social network hanno conquistato sempre più persone: la rete è un vero e proprio mass medium e le persone trascorrono sempre più tempo a leggere notizie sui siti web o attraverso applicazioni che non sulla carta stampata.

Figura 7.8 – Modello semplificato della catena pubblicitaria digitale: Inserzionista, Intermediario di Pianificazione, Editore.

Se a ciò aggiungiamo che la dimensione dell’intermediario di pianificazione sta diventando sempre più forte e invasiva e che spesso quest’ultimo è anche editore sul canale digitale, comprendiamo meglio come sia stato messo in difficoltà tutto il mondo dell’editoria, soprattutto di quella che non si è saputa adattare velocemente al cambiamento e che ha vissuto forse per troppo tempo al di sopra delle proprie possibilità.

Infine il nuovo editore online moderno (non la versione digitale dell’editore tradizionale) ha un vantaggio competitivo enorme rispetto a quello online: non paga chi realizza il suo contenuto, che è poi uno dei costi principali degli editori offline. Quando scrivete un post su Facebook oppure su Twitter, create del contenuto che viene letto dai vostri contatti digitali: siete proprio voi a formare l’audience e i lettori e questi social network non ripagano in alcun modo il vostro sforzo editoriale. Nessun utente Facebook o Twitter riceve dei soldi per quello che scrive, nemmeno quelli con migliaia di follower o coloro i quali ricevono migliaia di “mi piace” e condivisioni sociali. Per questo, il vantaggio di questa nuova tipologia di editori moderni è enorme rispetto a quelli tradizionali. Inoltre, questi stessi soggetti non utilizzano le concessionarie e preferiscono, ove possibile, evitare anche i pianificatori. Qualsiasi azienda con un po’ di competenze in termini di social media marketing può impostare direttamente una campagna su Facebook in modo rapido, veloce e intuitivo. Serve almeno una competenza specifica interna, ma non c’è una reale necessità di andare da un’agenzia di pianificazione, né da una concessionaria per acquistare spazi: fa tutto Facebook e a dei costi irrisori rispetto ai media offline.

In ambiente di dispositivi mobili gli sviluppatori e proprietari dell’app sono gli editori e spesso si avvalgono anch’essi del contenuto generato dagli utenti all’interno della propria app per ottenere altra audience e aumentare il tempo speso sul proprio canale di contenuto. Avete quindi un’app con degli utilizzatori che stanno aumentando sempre di più e consumano tempo all’interno della vostra app. Questo anche perché l’avete distribuita gratuitamente affinché ottenesse la massima diffusione possibile. A questo punto difficilmente riuscirete a vendere direttamente della pubblicità sulla vostra applicazione, a meno che non siate in un settore di nicchia che conoscete molto bene. Avete bisogno di implementare un framework pubblicitario come publisher. Sostanzialmente, dovete definire, a livello software, quanti e quali spazi e in che modo verranno occupati dai messaggi pubblicitari all’interno della vostra app. Così definirete per esempio un banner nella parte superiore, oppure un’intera schermata ogni volta che un utente finisce un livello del vostro videogioco, o ancora addirittura uno spazio video tra un livello e l’altro, magari incentivando il videogiocatore a vedere tutto il video stesso. È quasi più complicato descriverlo che metterlo in atto. Passiamo quindi in rassegna i principali circuiti pubblicitari disponibili per chiunque abbia realizzato un’applicazione e senza barriere d’ingresso. Il mercato di questi nuovi intermediari è ancora alquanto frammentato, anche se si stanno delineando i principali player. Questo non significa che non ci sia spazio per altri, ma la base del funzionamento è più o meno sempre la stessa con leggere distinzioni che, nel tempo, tenderanno a scomparire, consolidandosi standard di mercato, come è successo per il web.

Tipologie pubblicitarie lato publisher, metriche e rapporti degli incassi e loro analisi

I due principali circuiti pubblicitari di base più semplici e immediati per un publisher sono quelli offerti dalle due piattaforme di maggior successo e integrate negli strumenti a disposizione degli sviluppatori. Apple si avvale del proprio circuito pubblicitario iAd, mentre Google ha acquisito il leader del mercato del mobile advertising, AdMob, per 750 milioni di dollari alla fine del 2009, e sta integrando, sempre più all’interno delle proprie piattaforme pubblicitarie più usate, AdWords[55] e DoubleClick. Esistono poi serie infinite di piattaforme minori e circuiti pubblicitari anche settoriali, per esempio specifici per il mondo dei videogiochi, che offrono strumenti più particolari e di nicchia. Come per le altre sezioni di questo libro non cercherò di spiegare il singolo pulsante o il singolo dettaglio di una piattaforma, perché probabilmente quel pulsante cambierà posizione dopo la pubblicazione cartacea del libro, o una determinata piattaforma verrà inglobata in una concorrente. Vorrei però far comprendere i concetti comuni a qualsiasi utilizzo come editore e come sfruttare al massimo e decidere quale sia la soluzione che meglio si adatta alla vostra app: i concetti e le regole rimangono sempre gli stessi, le piattaforme cambiano.

Chiunque voglia perseguire il modello di business pubblicitario deve precedentemente pensare a quali spazi, sia in termini di dimensioni, sia in termini di posizione, dedicandosi alla visualizzazione di messaggi pubblicitari.

A differenza di quanto avviene per le pagine web, consiglio di non abusare dei banner soprattutto sugli smartphone: dovete limitare assolutamente il numero dei messaggi a un solo e unico spazio. Il display a disposizione dell’utente è già piuttosto ridotto e le persone accettano di ricevere pubblicità per un servizio gratuito.

Quando parliamo di display sui dispositivi mobili dobbiamo avere chiare due variabili. Ci sono tipologie pubblicitarie molto differenti tra loro, che possiamo cercare di classificare nelle seguenti famiglie, a seconda dell’effetto lato utente del messaggio pubblicitario.

1.Banner standard statici e animati.

2.Banner espandibili.

Figura 7.9 – I banner presenti in una pagina web sono numerosi rispetto alla stessa pagina su smartphone, che invece presenta solo un’inserzione pubblicitaria.

3.Floating banner.

4.Interstitial banner invasivi.

5.Banner opzionali con incentivo utente.

1.Banner standard statici e animati: quelli tradizionali sono i più comuni all’interno delle applicazioni di utilizzo quotidiano ed editoriali, così come ormai implementati nella maggior parte degli m-site che perseguono un modello di business sempre di matrice pubblicitaria. Esistono alcuni formati differenti in termini di dimensione, oltre una decina, anche se i banner più utilizzati sono quelli da 320×50 pixel e 300×50 pixel; le altre misure variano fno alla più piccola di 88×31 pixel, la cosiddetta microbar. Per applicazioni su tablet esistono formati anche leggermente più grandi. I banner possono essere statici oppure animati; lato inserzionista consiglio questi secondi perché catturano di più l’attenzione dell’utente. Il clic dell’utente sull’app genera normalmente il passaggio a una pagina web oppure, per la pubblicità delle applicazioni, direttamente alla scheda dell’app all’interno dello store, distante solo un clic dal download.

Figura 7.10 – Due esempi di banner standard 300×50 pixel.

2.Banner espandibili: questa tipologia di messaggio pubblicitario è identica alla precedente, ma al clic dell’utente il banner si espande a occupare tutta o una porzione dello schermo del dispositivo mobile mostrando ulteriore contenuto di qualsiasi tipo e interattivo: un video, un catalogo, delle immagini di prodotti. Questa tipologia di creatività è molto utilizzata nel settore automotive dove all’espansione del banner parte un video pubblicitario del modello di auto. Il livello di invasività aumenta.

Figura 7.11 – Un esempio di banner espanso: all’inizio è un banner standard ma, in caso di interazione dell’utente, si espande fino a occupare anche tutto il display del dispositivo mobile.

3.Floating banner: i messaggi galleggianti sono messaggi pubblicitari molto simili ai precedenti, ma sostanzialmente ancorati al dispositivo dell’utente e non al contenuto della scheda. In parole molto più semplici, il banner rimane fsso anche durante lo scrolling della pagina dell’utente. In questo modo il messaggio pubblicitario viene memorizzato di più dall’utente, poiché è sempre visibile a qualsiasi altezza dello schermo.

Figura 7.12 – Esempi di floating banner ancorati alla scheda anche in caso di scroll.

4.Interstitial banner: i messaggi interattivi spiccano nel gruppo delle tipologie pubblicitarie più invasive all’interno dei dispositivi mobili. Di solito si presentano sotto forma di testo e/o di immagine e di video e compaiono sullo schermo dell’utente in modo casuale, oppure al raggiungimento di un determinato evento: per esempio, ogni volta che completo un livello di un videogioco oppure quando salvo un’immagine modifcata con un’app editor di immagini. L’inserzionista riesce a catturare l’attenzione dell’utilizzatore perché è praticamente impossibile non guardare questi formati. I banner interattivi devono essere chiusi manualmente dagli utenti e questo “obbligo” rende la pubblicità molto invasiva. Ci vuole molta creatività per creare un banner interattivo divertente, che invogli realmente l’utente all’interazione con lo stesso: a volte vengono inseriti dei mini giochi, altre dei video completi. Dal punto di vista del publisher e di chi deve guadagnare con la sua app dalla vendita di simili spazi, questa soluzione è molto rischiosa: una simile tipologia di banner molto remunerativa genera anche un alto tasso di abbandono dell’app. A meno che non abbiate un’app realmente unica o non siate un grande editore con contenuto unico e di qualità, obbligare l’utente della vostra applicazione a vedere 30 secondi di video ogni volta che fnisce un livello può far sì che l’utente abbandoni il vostro gioco.

Figura 7.13 – I banner interattivi: quelli che vengono pagati con un CPM più alto di tutti, ma che sono molto invasivi rischiando di fare perdere utenti all’app.

5.Banner opzionali con incentivo utente: i motivi dell’invasività dei banner interattivi diminuiscono utilizzando questa tipologia rispetto ai precedenti. Non tutti possono però utilizzare questa tipologia di formati, che sono molto remunerativi, ma che non sono adatti a qualsiasi tipologia di app. Le app che possono sfruttare al meglio questa famiglia di banner sono certamente i videogiochi. Sostanzialmente, il calcolo lato publisher è che una visualizzazione di un video banner di 15 o 30 secondi viene pagata un certo valore per ogni mille visualizzazioni video prodotte, a seconda del video network affliato. Questo valore può essere quindi associato a un premio all’interno del vostro gioco, in modo che incentivi la visualizzazione del messaggio pubblicitario. È di fondamentale importanza scegliere dei formati tra quelli che permettano la scelta sempre all’utente del vostro gioco, magari limitandola solo ad alcuni momenti del gioco come alla fne di un livello o di un incontro sportivo. È il caso dell’app di calcio manageriale e giocato FirstStarSoccer2014, che ripaga l’utente che guarda un video, normalmente pubblicità di altre applicazioni, con un certo numero di crediti da spendere per allenare la squadra e comprare giocatori sul mercato e altri bonus e amenità varie del gioco.

Figura 7.14 – L’esempio di annunci pubblicitari con scelta dell’utente che ottiene un incentivo: FirstStarSoccer2014.

Nel caso in cui vogliate guadagnare dalla vostra applicazione principalmente attraverso la pubblicità, dovete avere numeri molto importanti se volete utilizzare formati poco invasivi e standard, oppure fornire forti incentivi agli utenti per poter utilizzare dei formati più invasivi, che però vengono pagati di più sul mercato. Potete, in alcuni casi, cercare di fare condividere più tipologie di formati tra loro. In ogni caso, dovete assolutamente pianificare quali banner vorrete utilizzare, con che invasività, e soprattutto dove posizionarli all’interno delle vostre interfacce. Per questo motivo, in questo modello di business, il design delle interfacce riveste un ruolo fondamentale e i grafici dovranno riuscire a far convivere l’usabilità con le esigenze di esposizioni pubblicitarie, anche invasive, all’interno della propria applicazione.

Bisogna preparare tutto a tavolino e cercare, a seconda dei formati scelti, la piattaforma più adatta per monetizzare la tipologia di traffico della vostra applicazione. Nel caso in cui la vostra app fornisca dei servizi di geolocalizzazione, potreste optare per dei network che comprano e vendono questo tipo di pubblicità: iper locale dell’utente in mobilità, una delle soluzioni marketing future più intriganti. Se invece avete a disposizione un’app del meteo godrete, oltre ai dati geografici del GPS dell’utente, anche di quelli di intenzione di spostamento (se da Milano guardo il meteo di Desenzano del Garda per il weekend, probabilmente sarò là durante quel weekend). Esistono poi servizi che intrecciano il dato meteorologico: nevica? Lo spazio per un inserzionista che vende antigelo per auto o catene vale moltissimo in quel preciso momento. Sostanzialmente, avete anche qui bisogno di una chiara strategia iniziale che vi aiuti a trovare delle soluzioni che permettano messaggi anche invasivi, ma dove il controllo rimanga sempre nelle mani dell’utilizzatore finale. L’utente moderno è disposto a pagare in termini di “visualizzazioni pubblicitarie” per ottenere in cambio un servizio gratuito.

La pubblicità, nel mercato digitale, viene venduta in modo diverso rispetto a quella dei canali tradizionali. Da sempre l’inserzionista ha pagato un costo fisso per un determinato spazio pubblicitario in un determinato arco temporale: compro la quarta pagina di un quotidiano nazionale per 3 giorni in un mese a un costo X; acquisto 20 passaggi in radio di 15 secondi cadauno a un costo Y; investo in 20 spot televisivi a una determinata ora in un determinato giorno della settimana. Sostanzialmente l’investitore sapeva sempre prima il costo di una campagna e il publisher sapeva a priori quanto avrebbe guadagnato per quella inserzione. Tutto molto semplice e anche un po’ noioso. La rivoluzione più importante che ha portato da sempre con sé il digitale nel mondo della comunicazione e del marketing è la sua misurabilità: per la prima volta esiste un mass medium che è misurabile in modo censuario. Quando compro una pagina di un giornale cartaceo, mi affido ai dati della tiratura (e a quelli certificati Audipress) per capire quante persone sono state raggiunge dal messaggio pubblicitario; il tutto si basa su dati presunti e su panel, ovvero gruppi di persone intervistati da aziende che fanno ricerche di mercato per capire se abbiano o meno visto la campagna pubblicitaria e se la ricordano. Queste sono tutte attività, accessibili solo a pochi, sui soliti canali degli editori ma con poco controllo sull’investimento da parte dell’inserzionista. La misurabilità del digitale ha portato un vero e proprio terremoto nel consolidato mondo pubblicitario tradizionale e nel marketing in generale permettendo la nascita del cosiddetto marketing a performance: pago un’inserzione in base alla sua efficacia misurata in modo censuario. Non si paga più uno spazio fisso a un costo fisso ma a seconda di quante volte è effettivamente comparso il messaggio pubblicitario: sono le cosiddette campagne Pay per Impression. Il mercato è andato oltre e, Google in primis, ha insegnato a tutti il marketing a performance, dove la performance di base è costituita dal clic dell’utente sul messaggio pubblicitario. L’inserzionista non paga quando il suo annuncio viene visualizzato, bensì se e solo se l’annuncio viene cliccato da chi lo visualizza: sono le cosiddette campagne Pay per Clic. Altri circuiti pubblicitari, come per esempio Tradedoubler, vanno ancora più a fondo nella performance: non pago l’esposizione pubblicitaria, non pago nemmeno il clic, ma se e solo se l’utente si registra alla mia newsletter o scarica un catalogo in PDF. In generale, pago ogni qualvolta un navigatore compie un’azione che reputo essere un obiettivo delle mie attività online. Chiaramente, più è importante l’obiettivo, più alta sarà la somma pagata al raggiungimento dello stesso da parte di un inserzionista. Queste sono le cosiddette campagne “Pay per Lead”, dove per lead si intende appunto il fatto che l’utente, partendo da un annuncio pubblicitario, è stato condotto a compiere un’azione obiettivo dell’inserzionista. Nello stesso modo, per coloro i quali vendono direttamente online, è possibile anche l’investimento in modalità “Pay per Sale”, dove l’inserzionista paga il publisher se e solo se l’utente, dopo avere cliccato il messaggio pubblicitario, naviga l’e-commerce e compra effettivamente dei prodotti o dei servizi.

È chiaro quindi che maggiore è la performance che richiedo, maggiore è il prezzo che dovrò pagare. In tal senso, lato publisher, la pubblicità a performance è molto più rischiosa rispetto a quella per numero di visualizzazioni, ma potenzialmente più lucrativa. Dal punto di vista di chi vende gli spazi pubblicitari però è molto pericoloso affidare tutte le proprie posizioni a performance in quanto ho molta meno certezza sulle entrate pubblicitarie delle mie attività digitali.

Figura 7.15 – La piramide del marketing a performance.

A livello mobile, per il momento, la performance si è spostata poco verso la parte alta della piramide, restando per lo più confinata nei primi due livelli. Normalmente, i miei spazi pubblicitari vengono pagati in base a quanti clic ricevono dai miei utenti e, in altri casi, anche in base a quante volte le schede della mia app hanno visualizzato i messaggi pubblicitari. Si stanno comunque evolvendo diversi sistemi per far pagare anche in base al numero di download di un’applicazione, circuiti pubblicitari che di solito usano spot in seguito a promozioni di prezzo. In generale, quindi, guadagnerete dalle impression e dai tap (clic col dito). Vediamo quindi di definire le metriche base della pubblicità dal punto di vista di chi vende i suoi spazi.

Tabella 7.3 – Un esempio di rendicontazione delle campagne.

Richieste: ogni qualvolta una vostra scheda viene caricata dal dispositivo dell’utente, lo spazio predisposto dai vostri grafci e programmatori invoca (attraverso un codice cosiddetto “invocation code”) il circuito di advertising chiedendo di riempire lo spazio pubblicitario con un messaggio. Il numero di richieste corrisponde quindi a quante volte il vostro sistema ha chiamato un circuito pubblicitario, sostanzialmente dicendosi disponibile ad accettare un’inserzione di un determinato formato e di una delle famiglie precedentemente descritte. Il publisher può, attraverso pannelli di controllo forniti dalle varie piattaforme, inibire determinate categorie di inserzionisti, di parole chiave non accettate e anche escludere puntualmente dei singoli messaggi, in quanto, per esempio, pubblicizzano applicazioni concorrenti alla nostra. Nel caso abbia un sito di meteo, cercherò di escludere qualsiasi altro inserzionista di app presenti nella mia stessa categoria. Le richieste non corrispondono necessariamente alle schede viste della vostra applicazione sostanzialmente per due motivi principali: a volte la scheda viene caricata, ma l’utente la cambia talmente velocemente che la richiesta non parte nemmeno dalla nostra applicazione. Ho una scheda vista ma nessuna richiesta per la mancanza di tempo. Dall’altro lato, nel caso di permanenza prolungata sulla scheda, il vostro sistema potrebbe effettuare più richieste al circuito pubblicitario. Pensiamo all’app di un editore sportivo che scrive notizie e articoli sugli incontri di vari sport: i lettori rimarranno su alcuni articoli anche per 2 minuti, per esempio, per leggere tutto il pezzo giornalistico. Se il nostro circuito pubblicitario ruotasse gli annunci ogni 30 secondi, per ogni scheda di articolo letta avrò 4 richieste verso il circuito pubblicitario (2 minuti diviso 30 secondi).

Impression: ogni qualvolta un’unità pubblicitaria viene caricata dalla vostra applicazione, viene fatta una impression. Questa metrica sostanzialmente indica quante volte è stato visualizzato un messaggio pubblicitario. Poiché una singola impression vale molto poco in termini monetari, nel caso in cui il pagamento sia ad impression (modello Pay per Impression), normalmente il prezzo di vendita viene defnito non per la singola visualizzazione, ma per blocchi da 1.000 impression. Si defnisce CPM, appunto, il Cost per Mille (si noti, in un mondo ricco di inglesismi, l’utilizzo della M latina per indicare 1.000). Così, se decido di vendere i miei spazi a 2,00 euro CPM, ciò signifca che ogni mille messaggi pubblicitari visualizzati ricaverò 2,00 euro; se non ragionassimo in termini di mille impression, ma per singola, ogni volta che viene visualizzato un banner incasso di 0,0002 euro, si avrebbero numeri con troppe cifre decimali che danno fastidio in fase di analisi, calcolo e comparazione. Lato publisher non ho il controllo sulla tipologia di marketing a performance decisa dall’inserzionista: alcune impression saranno pagate a PPI, altre impression solo a tap e così via. Ho quindi una situazione mista molto complessa e per questo normalmente nelle dashboard delle piattaforme non viene calcolato il singolo CPM così come il singolo CPT (Cost per Tap/Clic). Non tutte le richieste, come si vede anche dalla tabella, vengono “riempite” con un’inserzione pubblicitaria. Questo principalmente perché, a differenza del web, il mercato del mobile advertising è molto recente e non sono sempre presenti inserzionisti che vogliono imbastire campagne in tutto il mondo. Nel caso in cui la vostra applicazione venisse utilizzata in Paesi in via di sviluppo, potrebbe succedere, e succede spesso, che non ci sia nemmeno un inserzionista con campagne attive verso quell’area geografca, un fatto molto meno remoto di quanto si possa immaginare.

Tasso di riempimento (fll rate): questo tasso fa capire immediatamente se sto sfruttando e in quale percentuale la mia audience potenziale. Nell’esempio riportato su 1.200 richieste ho ricevuto solo 1.000 messaggi pubblicitari: il che porta a un tasso di riempimento pari all’83,33%. Ci sono state 200 richieste che non sono state esaudite dal circuito pubblicitario, fenomeno che dipende essenzialmente dai mercati dove è più utilizzata la mia app. Con il mercato pubblicitario più maturo sui dispositivi mobili dovrei arrivare a un tasso di riempimento prossimo al 100%.

Tap/Clic: i clic sui dispositivi mobili si chiamano tap. Questa metrica indica, appunto, quante volte i messaggi pubblicitari che ho mostrato ai miei utenti siano stati cliccati dagli stessi. Poiché la maggior parte delle revenue pubblicitarie derivano da una simile tipologia di marketing a performance, è molto importante tenere d’occhio questa metrica o meglio la successiva.

TTR (Tap Through Rate): è la metrica equivalente al CTR (Clic Through Rate) della pubblicità sul web e viene calcolata dividendo il numero di tap per il numero delle impression: TTR=Tap/Impression%. Il TTR indica quale sia la percentuale di tap in relazione a quante impression siano state erogate: un conto è ricevere 10 clic per un’app che ha mostrato un milione di banner, altro conto se ricevo 10 clic per un’app che ha mostrato 100 messaggi pubblicitari. Più alto è il TTR, più guadagnerete. Le variabili principali in gioco che condizionano il TTR sono sostanzialmente tre:

1.Tipologia di banner: alcuni annunci sono più accattivanti di altri e costruiti meglio. Gli utenti tendono a cliccare di più messaggi creativi e ben costruiti piuttosto che banner piatti dove non si capisce quasi nemmeno che cosa stia pubblicizzando l’inserzionista. Lato editore non potete condizionare in nessun modo questa variabile.

2.Posizione del banner: a volte spostare un pulsante o un elemento all’interno di una scheda di un’app (e anche in un sito web) può cambiare radicalmente le performance della pagina: la posizione del banner, anche relazionata al tipo di formato e famiglia, è di fondamentale importanza. Provate a modifcare la disposizione dei messaggi pubblicitari nella vostra app e guardate se e come cambia il TTR in seguito alla modifca: con pochi test otterrete certamente le soluzioni migliori per la vostra app e per la vostra audience.

3.Contestualizzazione dell’inserzionista: anche questo punto è molto importante e lato publisher avete un controllo più o meno ampio a seconda del circuito pubblicitario al quale aderite. Nel caso in cui compaia un messaggio pubblicitario nella vostra app del meteo di catene da neve mentre siamo a luglio, in Italia, e sto guardando le previsioni di Olbia, diffcilmente farò un tap sull’annuncio, completamente decontestualizzato. Lo stesso messaggio fatto a gennaio, sempre in Italia, mentre guardo le previsioni di Selva di Val Gardena, sarà certamente molto più cliccato. La vostra app parla di sport? Cercate di selezionare inserzionisti che producono attrezzatura sportiva, ma anche food & beverage ecc.

eCPM (equivalent/effective Cost Per Mille impression): l’eCPM è la metrica fondamentale per chiunque venda spazi pubblicitari. Abbiamo visto che il publisher non ha un controllo diretto sulla tipologia di pubblicità che arriverà all’interno delle proprie schede, in quanto il tipo e il formato viene pianifcato dall’inserzionista in relazione al circuito pubblicitario in cui ha investito i propri soldi. Di volta in volta riceverò quindi dei banner pagati a CPM. Altre volte, attualmente la stragrande maggioranza, verrò pagato in base a quanti tap hanno fatto gli utenti; altre volte ancora in base a quanti hanno scaricato una determinata applicazione. Lato publisher, devo comunque riuscire a confrontare gli spazi dedicati tra loro in modo equivalente eliminando la componente a performance e riducendo il tutto alla metrica base del CPM. L’eCPM si calcola dividendo l’incasso per le impression, quindi nella Tabella 7.3: eCPM = 50,00 dollari/100.000 = 0,50 dollari.

È più complesso descrivere a parole il concetto dell’eCPM e tutte le altre metriche che non con il seguente caso reale della Figura 7.16.

Figura 7.16 – Tabella della piattaforma di Apple iAd, con dati reali giornalieri di un’app e distribuzione delle performance degli incassi pubblicitari per area geografica.

In questa figura viene rappresentato l’andamento dell’incasso pubblicitario giornaliero per Paesi di un’applicazione distribuita. La prima colonna “revenue” indica quanti soldi ho incassato per la vendita degli spazi pubblicitari seguita dalle altre metriche che abbiamo analizzato per poter esaminare il valore pubblicitario. Vediamo come leggere la tabella. Partiamo dall’Australia: gli utenti australiani dell’app non sono moltissimi, il nostro software ha inviato 16 richieste al circuito di iAd geolocalizzate in Oceania. Le richieste sono state quasi tutte esaudite dal circuito, generando 15 impression, ovvero il 93,75% dell’audience potenziale. La piattaforma di iAd non fornisce il numero di Tap, ma solo il TTR. Avendo impression e TTR posso calcolare a ritroso i tap; vediamo che in Australia ho avuto un TTR altissimo: 6,67%, ovvero 1 tap per le 15 impression erogate: 1/15=6,67%; il fatturato di 0,10 dollari deriva molto probabilmente, ma non sicuramente, da quell’unico tap in un modello di pubblicità a performance Pay per Tap/Clic. Analizziamo ora i dati generati dagli utenti francesi: il fill rate è molto simile a quello australiano e anche a quello americano e italiano; sono tutti mercati abbastanza maturi nel mondo della pubblicità mobile e quindi si trovano quasi sempre inserzionisti disponibili. Vediamo una cosa molto interessante sulla Francia: il TTR è dello 0,00%, ovvero nessuno ha cliccato (o meglio tappato) su nessuna delle 473 visualizzazioni di annunci a pagamento, eppure ho incassato lo stesso 9 centesimi di dollaro. In questo caso, sono certo che ho ricevuto quel pagamento perché gli inserzionisti erano in un modello di marketing a CPM, ovvero pagavano per essere visualizzati a prescindere dalle performance della campagna e dai tap degli utenti. Le campagne CPM sono le migliori, insieme a quelle con incentivo lato utente, per monetizzare realmente la propria audience. Per confrontare dati così disomogenei tra loro in termini sia quantitativi sia di tipologia è fondamentale l’utilizzo dell’eCPM; è stata la prima metrica presentata da Apple nel suo report, dopo quella fondamentale dei soldi incassati. L’eCPM mi dice quanti soldi avrei guadagnato, a parità di performance, nelle differenti aree geografiche per ogni mille visualizzazioni di banner. Ovvero, se in Australia avessi raggiunto le 1.000 impression, a parità di TTR avrei incassato 6,56 dollari, in Italia 0,65 dollari e così via. Solo in questo modo, e con numeri più consistenti di quelli dell’Australia, posso capire quale sia il mio guadagno medio e comparare diverse campagne tra loro. Qui l’esempio di distribuzione è semplicemente geografico, ma posso farlo per tipologia di banner, per data e così via. Rimane di fondamentale importanza confrontare i parametri e le metriche corrette per comprendere appieno la situazione perché il vostro obiettivo è di massimizzare sempre più l’eCPM.

Prima di affrontare qualsiasi modello di business che si basi sull’advertising, vi consiglio vivamente di comprendere esattamente i meccanismi della pubblicità digitale e di fare un po’ di esperienza, magari con qualche pagina web di qualche blog o sito Internet a disposizione, per capire i soldi che ci sono in gioco. I numeri presentati sono reali, per guadagnare con la pubblicità nelle app dovete creare dei volumi di impression enormi, oppure perseguire la strada dei banner con incentivo. Se pensate che un’app utilizzata da un migliaio di persone anche quotidianamente possa pagarvi uno stipendio vi sbagliate di grosso… un’altra leggenda metropolitana da sfatare: sono molto molto pochi i soggetti che fanno migliaia di dollari con la pubblicità.

52. Booking.com è una delle più importanti OTA (Online Travel Agency) a livello mondiale, fortissima a livello europeo. Il concetto innovativo è il sistema di rating degli hotel e di giudizi degli ospiti (che possono effettuare solo se hanno prenotato attraverso il sito di booking.com). A fronte di una percentuale sull’importo totale del soggiorno prenotato attraverso Booking, gli hotel hanno maggiore visibilità.

53. SkyScanner: un motore di ricerca per voli aerei che permette la comparazione di prezzo delle diverse compagnie aeree e ha un sistema di ricerca molto fessibile che consente il confronto su un mese intero.

54. È molto più facile vedere che descrivere il funzionamento della realtà aumentata: ecco quindi i due video Catalogo 2013 https://www.youtube.com/watch?v=ETtQGOJES8Y e Catalogo 2014 https://www.youtube.com/watch?v=uaxtLru4-Vw.

55. La piattaforma di Google AdWords, utilizzata da centinaia di migliaia di utenti, è forse il più importante mercato pubblicitario nel mondo digitale se consideriamo le sue estensioni. Nata per l’acquisto di spazi pubblicitari contestualmente alle parole utilizzate dagli utenti nel motore di ricerca di Mountain View (Advertising delle Parole/Words appunto) e collegata anche alla rete per publisher web AdSense, è stata poi ampliata collegandola prima alla rete display (i mitici banner, ma fa più trendy chiamarli display dopo la bolla del 2000) della piattaforma DoubleClick, acquisita per 3,1 miliardi di dollari nel 2007 da Google, e poi ulteriormente sviluppata collegandola al mondo mobile con AdMob comprata per 750 milioni di dollari alla fne del 2009. Con queste due acquisizioni e il suo predominio nel mercato della search, l’azienda di Mountain View si è assicurata una posizione molto importante sul mercato della pubblicità digitale e il valore del suo titolo azionario quotato al NASDAQ rispecchia la sua posizione di leader del mercato.

CAPITOLO 8

FINALMENTE NEGLI STORE!

Chi va piano va sano e lontano

Sono nato nell’epoca delle stragi del sabato sera. I miei genitori erano terrorizzati ogni volta che prendevo l’automobile da neopatentato e la litania “chi va sano va piano e lontano” o il semplice urlo “vai piano!” era un classico ogni volta che uscivo con le chiavi dell’auto in mano. Questo consiglio imperativo e pieno di passione lo voglio rivolgere a tutti gli sviluppatori di applicazioni: andate piano, soprattutto nel viaggio della sottomissione della vostra applicazione all’interno dello store.

Oltre a leggere con attenzione le linee guida degli app store sul tema della pubblicazione, potete, e consiglio vivamente di farlo, prendere confidenza con i pannelli di sottomissione dell’app store che utilizzerete fin dall’inizio del vostro progetto, simulando la creazione di una vera e propria app demo per vedere come sono fatti i vari passaggi e avere ben chiaro tutto il processo di sottomissione.

Mentre i grafici e i programmatori sono al lavoro, il team di supporto dovrebbe studiare tutti i singoli step e pensare già a tutto il materiale da produrre e da preparare.

Suggerisco, per i progetti di breve durata di sviluppo non superiori ai quattro o cinque mesi, di bloccare fin da subito il nome della propria applicazione. Una volta aperto il record all’interno dell’app store, il negozio elimina quel nome dalla possibilità di scelta da parte di altri sviluppatori (non possono convivere due o più app con lo stesso nome). Sostanzialmente, compilare la prima parte della submission vi permette di “bloccare un nome”. Consiglio di farlo anche per i progetti medio lunghi, quando si è giunti entro quattro o cinque mesi dalla fine dello sviluppo. In questo modo, non vi troverete nella scomodissima, e a volte drammatica, situazione di accorgervi che il nome che avevate dato alla vostra idea geniale (e tutta la grafica di supporto creata) è stato già utilizzato da un’app che magari fa tutt’altro rispetto alla vostra, pubblicata dieci giorni prima sull’app store.

Normalmente i negozi permettono di bloccare un nome di app per un periodo di sei mesi, per questo ho dato delle scadenze a quattro o al massimo cinque mesi.

Come già spiegato parlando delle fasi importantissime del Beta Testing delle app, la fretta è uno dei peggior nemici della vostra app: non fatevi coinvolgere eccessivamente dall’entusiasmo al momento dell’uploading e pensate sempre a questi due concetti. Innanzitutto, è inutile correre, soprattutto su iOS: una volta che avrete finito il processo di sottomissione dell’app, bisognerà attendere alcuni giorni perché i negozi controllano uno a uno i progetti che vengono sottomessi prima di renderli pubblici e scaricabili all’interno dello store. Questo processo in media dura dai 6 ai 9 giorni per iOS e da 1 a 3 giorni per il mondo Android sotto Google Play. È quindi perfettamente inutile affrettarsi e correre come dei pazzi verso il binario per prendere un treno che partirà solo dopo una settimana dalla stazione. La seconda ragione per cui andare piano è quella del rischio di fallimento totale di un progetto, nel caso in cui l’app dovesse avere qualche tipo di problema in fase di lancio.

Nel primo momento in cui viene pubblicata l’app, normalmente gli store cercano di “favorire” almeno per qualche ora o un paio di giorni le app appena pubblicate, sia fornendo delle sezioni ad hoc agli utenti dello store, sia inserendo le app all’interno delle categorie selezionate in una posizione medio-alta della classifica. Ciò serve a permettere a un numero iniziale di download limitato, ma congruo, di vedere la risposta degli utenti fin dall’inizio. Questo blocco iniziale di download, che viene normalmente favorito alle nuove app, deve essere sfruttato al massimo da chi sviluppa; le prime recensioni e il diffondersi immediato di un’app permettono di rimanere nelle parti alte della classifica e ottenere più giorni di visibilità. La visibilità, negli store, è uno dei fattori di maggiore successo di qualsiasi applicazione.

Figura 8.1 – La categoria delle app nuove dell’Apple App Store. La presenza nelle prime ore o nei primi giorni all’interno di questa categoria permette una buona visibilità e diffusione iniziale della stessa.

Bisogna arrivare quindi preparati e con tutto il materiale da fornire agli store già pronto nel momento in cui si decide di sottomettere l’app; bisogna quindi avere una vera e propria launch checklist (una lista della spesa, direbbe mia mamma) ed essere sicuri di aver completato e pronte tutte le attività necessarie. L’improvvisazione, in questo momento, deve essere completamente esclusa perché tutto deve essere pianificato a tavolino.

Infine, ricordatevi che la sottomissione non è il traguardo finale del vostro progetto, anzi, è solo l’inizio della lunga corsa verso il successo della vostra applicazione. L’errore più comune di moltissimi developer è di pensare di essere arrivati alla fine del lavoro una volta che l’app è stata approvata; una visione molto tecnica e limitata. Al momento della pubblicazione nel negozio, siete sulla linea di partenza, non di arrivo. I casi di app che sono esplose e hanno avuto successo per caso si contano sulle dita di una mano e le probabilità sono infinitamente basse (sostanzialmente, il jackpot del superenalotto). Tutte le app che vogliono ottenere un ritorno sull’investimento hanno bisogno di un supporto al lancio e durante tutto il loro ciclo di vita: la pubblicazione è solo l’inizio del lavoro, adesso viene la parte di marketing e comunicazione che è decisiva per decretare il successo della vostra idea. Non “correte” come dei disperati, siamo solo all’inizio: c’è ancora tanta strada da fare.

Il marketing dell’app comincia da qui: launch checklist

Spesso l’utente mobile all’interno degli app store esegue delle ricerche per trovare un software che soddisfi un proprio bisogno personale, oppure esplora le categorie sfogliando decine di app. Il processo di selezione è spesso rapido e il tempo dedicato a ogni singola applicazione è veramente ridotto, soprattutto per quelle distribuite gratuitamente: all’utente non costa nulla il download, quindi può essere convinto con un bel nome, un’icona disegnata bene e una grafica accattivante attraverso gli screenshot con un giudizio medio-alto di altri utenti. Spesso, chi guarda una scheda dell’app presta quindi attenzione molto velocemente al prezzo, al rating degli utenti e guarda le immagini per cercare di capire che tipo di app sia e come sia disegnata rispetto ad altre concorrenti. Per le app a pagamento la descrizione è molto importante. Sostanzialmente, la scheda che dovete compilare per sottomettere l’app è il primo biglietto da visita che mostrate all’utente finale: è il packaging virtuale del vostro prodotto, non tangibile ma altrettanto importante quanto un imballaggio o una bella confezione. Non avete costi di stampa ed è un vantaggio enorme, ma non sottovalutate per questo motivo il modo in cui viene presentato il vostro prodotto finale.

Vediamo quindi di esaminare, come se fosse una vera e propria lista della spesa, tutto il materiale di cui abbiamo bisogno al momento della sottomissione, a prescindere dal fatto che stiate lavorando con iOS o con Android, Windows o qualsiasi altra piattaforma attuale o futura.

Nome dell’applicazione e dello sviluppatore.

Icona e Loghi.

Beta Testing concluso.

Processo di uploading chiaro.

Controllo del peso dell’applicazione.

Scelta del rating di età.

Scelta dei mercati e delle lingue della scheda.

Scelta di compatibilità dei device.

Scelta del prezzo e/o degli eventuali acquisti in-app.

Grafca di base con screenshot e video (per Google Play).

Grafca promozionale avanzata.

Categoria, Descrizione e Keyword (ASO).

URL Privacy, supporto clienti, promozionale.

Opzioni avanzate degli store: cloud, game center, circuito pubblicitario.

Solo una volta che avrete tutto il materiale della lista pronto e disponibile in tutti i formati richiesti e nelle varie traduzioni che volete rendere disponibili sarete davvero pronti a fare il login come sviluppatori all’interno della piattaforma dove volete pubblicare la vostra app, e cominciare tutto il processo per la sottomissione. Vediamo quindi nel dettaglio cosa e come preparare tutto il materiale necessario.

Nome dell’applicazione e dello sviluppatore: se siete arrivati fno a questo punto senza un nome e senza nemmeno avere chiaro come comparire, in termini di nome di sviluppatore dell’app, vi consiglio vivamente di ripartire dall’inizio di tutto lo sviluppo, perché state facendo un vero e proprio salto nel vuoto e non avete preparato un benché minimo supporto all’applicazione. Prima di compiere un vero e proprio parricidio della vostra idea, fate un bel respiro e cominciate a leggere dall’inizio questo libro o altro materiale disponibile in rete. Il nome dell’app è fondamentale e ne abbiamo già abbondantemente parlato. Deve essere molto chiara anche la strategia che intendete adottare nei vari mercati esteri. Dovete sapere già quindi se il nome dell’app sarà identico in tutti i mercati, oppure se cambierà di volta in volta. La scelta della localizzazione e dei mercati è uno dei punti successivi della presente lista. Inoltre, nel caso di app commissionate a uno sviluppatore, dovete avere chiaro cosa signifchi pubblicare direttamente oppure attraverso la software house che ha sviluppato la vostra idea. Il mio personale consiglio per qualsiasi app che persegua un modello di business a pagamento (sostanzialmente quelle a pagamento e con in-app purchase, ma anche quelle con revenue pubblicitaria) è quello di pubblicare direttamente. A fronte di una spesa annua abbastanza contenuta per essere developer (costi diretti dello store di circa un centinaio di euro annui ed eventuali costi di setup nel caso abbiate scarse conoscenze tecniche di utilizzo di piattaforme di complessità media) eviterete tutta una serie di passaggi e rendicontazioni fnanziarie inutili e molto fastidiose tra voi e lo sviluppatore. Anche questi aspetti devono essere chiari a tutte le parti fn dall’inizio del progetto e non certamente al momento della pubblicazione dell’app. Ricordatevi le tecniche spiegate per bloccare il nome della vostra applicazione già in fase di sviluppo della stessa.

Icona e Loghi: abbiamo già abbondantemente parlato di tutti questi aspetti e della loro importanza fondamentale. Il team grafco deve avere già tutte le icone e i materiali pronti nei differenti formati richiesti dal negozio di app.

Beta Testing concluso: avete già completato tutta la fase di testing interna ed esterna ove possibile, siete alla versione fnale (e iniziale 1.0) del vostro software. Lanciatelo un’ultima volta sui differenti dispositivi per i quali volete pubblicarla, giusto come gesto scaramantico. Un’ultimissima prova prima del lancio uffciale. Bene, tutto ok? Allora procediamo con la lista della spesa.

Processo di uploading chiaro: dovete avere già visto i vari pannelli e passaggi della fase di sottomissione dell’app, sapere già quali sono i fle e i formati dell’app di cui avete bisogno e non utilizzare mai fle compilati da piattaforme di terze parti non testati.

Controllo del peso dell’applicazione: la dimensione dell’app deve essere stata condivisa, sia per le questioni di distribuzione dell’app che, come sappiamo, può essere scaricata in 3G solo se rientra entro determinate dimensioni, altrimenti viene richiesta una connessione wi-fi, più veloce o perlomeno più stabile. Inoltre, per Google Play il processo di submission squisitamente tecnico cambia leggermente se il peso dell’app eccede di una certa dimensione (attualmente, 50 MB, ma sono numeri che cambieranno sicuramente). Per questi motivi, anche la dimensione dell’app è una scelta strategica da affrontare ben prima di questo momento.

Scelta del rating di età: dovete già sapere a quali utenti e per quali età renderete disponibile la vostra applicazione. I contenuti della vostra app sono adatti anche per i più piccoli? Il linguaggio del vostro videogioco contiene dei termini al limite? Lo store ha la sovranità di giudizio fnale, ma voi inizialmente dovete fare una sorta di autocertifcazione sull’età minima di utilizzo del vostro software. Cercare di pubblicare un videogioco contenente scene macabre e con morti sanguinose nella categoria di età adatta a 9+ potrebbe essere motivo di rigetto dell’app e di ritardi e perdite di tempo future. Chiaramente, per applicazioni del tutto “pulite” e adatte a ogni età potete allargare il campo d’azione. Un discorso a parte merita la categoria dei giochi: nel caso selezionaste un pubblico 4+, potrete classifcare la vostra idea anche per gli utenti più piccoli, sotto i nove anni, e inserirla nelle categorie minori per età. Sostanzialmente è ciò che avviene anche per i giocattoli fsici che presentano sempre un’indicazione di età obbligatoria per legge soprattutto in ambito audio, video e video ludico. Gli store seguono le logiche di classifcazione del PEGI (Pan European Game Information) europeo e dell’ESRB (Entertainment Software Rating Board) nordamericano l’Apple App Store fornisce una vera e propria tabella comparativa dei tre sistemi (Figura 8.2).

Scelta dei mercati e delle lingue della scheda: a questo punto dovete già avere molto chiaro a quali mercati volete rivolgervi. Per poter affrontare mercati esteri l’ideale è avere la vostra app tradotta in tutte le sue parti ed etichette nella lingua del mercato che si vuole perseguire. Capisco che non sia sempre facile, ma avere almeno l’app in inglese e possibilmente nelle altre lingue più parlate a livello mondiale apre degli orizzonti e soprattutto un’audience enorme che scarica quotidianamente milioni di applicazioni dai negozi. Pensate un po’ come avete già fatto col vostro sito Internet: utilizzate più o meno le stesse logiche se potete.

Figura 8.2 – Tabella comparativa del sistema di classificazione dell’Apple App Store con la scala PEGI e quella ESRB.

La scelta del multilingua è una delle primissime cose da affrontare nel progetto anche a livello tecnico. Il team di sviluppo deve sapere fin da subito che quell’app avrà bisogno di un numero di lingue aperto. All’inizio, magari saranno solo due o tre, ma che si possano espandere a piacimento. Gli sviluppatori creeranno un framework di sviluppo adatto a traduzioni rapide e poco costose dell’app per minimizzare i costi di gestione e di ampliamento del numero delle lingue. Pensate in grande: avete di fronte un grande pubblico e parlare nella loro lingua è una mossa vincente.

Scelta di compatibilità dei device: anche queste problematiche le dovreste avere già affrontate prima di arrivare a questo punto. Sapete già se avete un’unica versione per tablet e smartphone oppure se disponete di app dedicate a seconda dei vari dispositivi. Dovete anche già sapere su quali versioni del software operativo e fno a che versione obsoleta dell’hardware la vostra applicazione funziona. Il mondo di Android inoltre è molto frammentato in termini di risoluzioni e schermi: gli sviluppatori vi dovrebbero avere già parlato di tutto questo. Sapete quindi già quali sono le scelte che avete fatto in termini di dispositivi hardware ai quali offrirete la vostra app.

Scelta del prezzo e/o degli eventuali acquisti in-app: è al momento della sottomissione che dovrete “dichiarare” il vostro modello di business anche allo store: la vostra versione è premium? Free? Freemium o addirittura Paymium? (ovvero Pay con possibilità di acquisti ulteriori in-app). Anche in questo caso, se arrivate a questo punto senza avere chiare le risposte precedenti, vi consiglio vivamente di bloccare tutto e ricominciare da capo.

Grafca di base con screenshot e video (per Google Play): oltre all’icona, lo store richiede almeno alcune immagini dell’app da inserire nella scheda. Vi consiglio vivamente di utilizzare tutte le immagini che il negozio vi permette di inserire all’interno dello store per dare il massimo delle informazioni possibili all’utente. Fatelo anche in modo creativo, soprattutto per le app iOS, ovvero cercate di spiegare anche sugli screenshot determinate funzioni della vostra applicazione, cosa che un’immagine soltanto non riuscirebbe a dare. Gli screenshot andrebbero quindi corredati di immagini con delle scritte che facciano capire immediatamente le funzioni dell’app e cerchino di invogliare l’utente a cliccare sul tasto del download. Lo fa bene l’app “Emily – La tua sveglia personale” che, in un settore estremamente concorrenziale, fa capire fn da subito i suoi punti di forza e di unicità, le opzioni offerte dallo strumento e il design e la grafca generali dell’app. Una volta visualizzati gli screenshot non ho quasi nemmeno bisogno di leggere la descrizione testuale oppure lo faccio e approfondisco proprio perché ho guardato le immagini. Il trucco è sempre lo stesso: cercare di catturare l’attenzione degli utenti anche attraverso dei semplici screenshot.

Figura 8.3 – Gli screenshot “parlanti” dell’app “Emily – La tua sveglia personale” sono molto utili soprattutto in segmenti e categorie super affollate: l’utente confronta molto velocemente le app tra loro e dobbiamo cercare di catturare la sua attenzione avendo a disposizione pochissimi secondi di tempo.

Per il mondo di Google Play avete la possibilità di inserire un video della vostra app che possa far capire ancora meglio all’utente come funziona e che tipologia di software sia. Lo strumento del video è estremamente potente. Potete mostrare la vostra app in azione così come promuovere l’immagine del prodotto facendo intuire a tutti la vostra professionalità con video di marketing che suscitino interesse e coinvolgano l’utente. Qualunque sia la vostra scelta, vi consiglio vivamente di usare un video per far capire meglio come funziona la vostra app oppure quanto è accattivante e ben disegnata la grafica del vostro videogioco.

Figura 8.4 – Il video emozionale associato all’app Methodic, che cerca di spiegare l’app in modo commerciale, molto utile per convincere l’utente al download.

Grafca promozionale avanzata: se credete di aver fatto veramente un bel lavoro e che il vostro progetto sia degno di nota, allora credete anche che i team che revisionano le app degli store noteranno certamente il vostro lavoro.

La vostra app potrebbe essere selezionata dal team di Apple o Google o Windows e inserita all’interno degli store in alcune posizioni privilegiate. In questo caso il gestore dello store gestisce la comunicazione anche con altri formati oltre alla semplice icona dell’app. Egli ha bisogno, per esempio, di una serie di banner che potrebbe voler inserire nel caso che selezioni la vostra applicazione. Non esiste modo di essere sicuri della selezione, ma certamente mettere a disposizione allo store tutto il materiale di cui avrebbe bisogno aumenta moltissimo le possibilità di essere scelti per una comunicazione parallela. Il fatto di essere selezionati tra le migliori app di una determinata categoria può portare a dei risultati clamorosi in termini di download. Questo migliora moltissimo la posizione all’interno della categoria in cui l’app concorre, portando ulteriori download. Sostanzialmente, la scelta editoriale dell’app store può fornire quella spinta iniziale necessaria per innescare una diffusione virale della vostra applicazione e potrebbe quindi decretare il successo della vostra idea. Fornire tutto il materiale necessario per poter venire inclusi in queste scelte è un vantaggio non trascurabile e non comporta un costo enorme, soprattutto se paragonato a tutto il resto del lavoro. Leggete bene le linee guida degli store dove intendete pubblicare per capire che formati dovete fornire e in quali passaggi. Normalmente, sono tutti campi opzionali e non obbligatori in fase di uploading, ma se fossi in voi non li reputerei tali.

Categoria, Descrizione e Keyword (ASO): oltre al nome, la descrizione e le keyword giocano un ruolo chiave rispettivamente in ambiente Google Play e Apple App Store per essere posizionati in modo dignitoso all’interno della classifca dello store. Esse sono la base della Application Store Optimization, l’equivalente della SEO (Search Engine Optimization) riferita al posizionamento dei siti Internet. Della scelta di categoria abbiamo già abbondantemente parlato e al momento della sottomissione saprete già esattamente a quale o quali categorie associare la vostra app. La descrizione è un testo molto importante ai fni del posizionamento per il mondo Google Play, mentre non conta nulla per iOS, ma una buona descrizione può determinare il download o meno di un’app. Il campo delle parole chiave è determinante per il negozio di Apple e per ottenere il massimo della visibilità, perlomeno a livello semantico, durante le ricerche degli utenti dello store. In fle .doc o .xls dovete avere già tutto questo materiale testuale pronto, con i relativi controlli di conteggio delle parole, per essere sicuri di non eccedere lo spazio massimo fornito dal negozio in termini di battute.

URL Privacy, supporto clienti, promozionale: oltre a operare internamente allo store, il processo di sottomissione vi obbliga anche ad agire esternamente. La vostra app deve essere corredata da alcuni link più o meno obbligatori che variano da negozio a negozio: il fatto di dover inserire dei collegamenti ha come naturale conseguenza quello di dover avere delle pagine web che rispondano, in termini di contenuti, alle linee guida del sistema di distribuzione di app che avete scelto. In generale, possiamo classifcare tre tipologie di link che considero molto importanti a prescindere dalla loro obbligatorietà e che sono da suggerimento e stimolo per comprendere quanto sia importante fornire supporto all’applicazione anche esternamente allo store, come vedremo quando parleremo di marketing delle app:

1.Link e pagine relative alla privacy: una o più pagine che descrivono come utilizzate eventuali dati degli utenti e a che scopo, così come tutte le altre informazioni obbligatorie per legge che dipendono anche dal Paese dove sviluppate l’applicazione. Il tema della privacy è meramente burocratico nel caso in cui non trattiate i dati degli utenti, mentre diventa sempre più sensibile e complesso mano a mano che utilizzate o avete l’accesso a dati di utenti e li utilizzate a scopi pubblicitari. Nel caso in cui desideriate pubblicare app per bambini, vi consiglio di prestare molta attenzione per produrre la giusta e adeguata documentazione e informare in modo semplice e trasparente i vostri utenti in relazione ai loro dati.

2.Supporto e mail assistenza ai clienti: dovreste predisporre almeno una pagina web dove fornite i contatti e le modalità con le quali gli utenti vi possono contattare in caso di problematiche riscontrate nell’utilizzo della vostra app o per svariati motivi. È molto importante cercare di ottenere il contatto con i propri utenti e dovreste quindi prestare molta attenzione e cura alla pagina di atterraggio dello store. Curare l’attenzione dell’utente e fornire un buon supporto crea un legame di fdelizzazione molto forte con la propria audience. Il vostro obiettivo è quello di trasformare una segnalazione, magari anche di un piccolo bug, della propria app in una recensione positiva di quell’utente anche in seguito al servizio di assistenza che sarete in grado di erogare.

3.Pagine di tipo promozionale: oltre ai link e alle pagine delle precedenti tipologie che sono obbligatorie all’interno degli store, vi consiglio di fornire un link a un sito oppure perlomeno a un mini sito sul web che sia di supporto per tutta la comunicazione e il lancio dell’app.

Opzioni avanzate degli store, dal cloud al gaming e ai circuiti pubblicitari: a seconda dell’app store dove intendete pubblicare la vostra applicazione, avete a disposizione più o meno opzioni avanzate per collegare la vostra app a sistemi dedicati del negozio di applicazioni che svolgono alcune funzioni standard. Le funzioni più comuni negli store sono le seguenti:

1.Opzioni di tipo cloud: avrete modo di selezionare le modalità di accesso della vostra app allo spazio sulla “nuvola” dell’utente collegato direttamente al proprio account unico dello store. Nel caso in cui la vostra applicazione si basi soprattutto su documenti e immagini, in particolare con fnalità lavorative, la sincronizzazione della vostra app con l’account cloud dell’utente potrebbe essere una funzionalità essenziale per la tipologia di progetto che trattate.

2.Opzioni di gaming: ogni piattaforma dispone di un centro unico per i videogiochi. Inoltre, esistono anche piattaforme multiplayer di terze parti alle quali potete collegare la vostra app gioco. È molto utile sfruttare il sistema precostruito di social gaming e di multiplayer predisposto dalla piattaforma dove pubblicate. Nel caso dell’Apple App Store, per esempio, potreste essere interessati a collegare il vostro gioco alle classifche del Game Center. In questo modo, tutti gli amici del centro di gioco collegati a quell’account potranno sapere che ho giocato alla vostra applicazione e decidere quindi anche loro di provarla. Gli elementi sociali all’interno dei giochi possono rivestire un ruolo determinante per il successo di un’app game.

3.Opzioni di scelta dei circuiti pubblicitari: nel caso in cui abbiate come modello di business quello collegato alla raccolta pubblicitaria, avrete già pianifcato molto tempo prima a quale circuito aderire e quali sono le rispettive modalità tecniche. Le piattaforme fornite agli sviluppatori tendono a coinvolgere gli stessi a utilizzare i loro circuiti pubblicitari proprietari. Abbiamo già lungamente trattato l’argomento della scelta degli spazi e delle modalità di annunci pubblicitari da pubblicare; qui dovete solo confermare le vostre scelte strategiche precedenti.

Il processo di sottomissione dell’Apple App Store

Possiamo suddividere la sottomissione al negozio di Apple in tre fasi distinte a cui assocerò alcuni screenshot presi dalla piattaforma di Cupertino all’inizio del 2014. Le schermate potranno cambiare, ma in sostanza le fasi e l’approccio che dovete avere in fase di pubblicazione della vostra app rimarranno sempre gli stessi.

1.Creazione iOS app Bundle ID.

2.Scelta del nome ed elementi base dell’app.

3.Inserimento dei metadata.

4.Uploading del codice compilato.

Le prime due fasi, come già spiegato, dovrebbero essere affrontate ben prima della fine dello sviluppo della versione 1.0 del vostro software, in modo da poter bloccare il nome della vostra applicazione e non renderlo disponibile agli altri sviluppatori e avere già interfacciato l’ID della vostra app e le opzioni avanzate di scelta dello store. Il blocco del nome avviene con la seconda fase della creazione all’interno di iTunes Connect, ovvero la piattaforma fornita da Apple a tutti gli sviluppatori iOS (che pagano un canone annuo per avere l’accesso al negozio lato publisher).

1.Creazione iOS app Bundle ID.

Questa fase dovrebbe essere già stata completata dalla parte tecnica del team di sviluppo. Sostanzialmente dovete indicare ad Apple un Identificativo (ID) univoco da attribuire al vostro progetto in modo che la vostra applicazione sia identificata fin dall’inizio e per qualsiasi rapporto tra piattaforma di sviluppo e gestore del negozio e del sistema operativo.

Innanzitutto dovete attribuire una descrizione al vostro ID, che non necessariamente deve coincidere col nome pubblico dell’app ma potrebbe avere un nome più progettuale, e dovete selezionare un codice alfanumerico fornito direttamente da Apple come identificativo univoco del progetto (Figura 8.5).

Il secondo step è se scegliere di attribuire un nome unico a un gruppo di app oppure se volete che ogni progetto abbia un suo identificativo univoco. Considerate la scelta dell’univocità come la migliore perché potrete avere rapporti individuali con le app di base del dispositivo (Figura 8.6).

Infine, potrete anche selezionare le opzioni avanzate di interfacciamento col sistema operativo dell’azienda di Cupertino per sfruttare determinate caratteristiche dei dispositivi mobili e interagire con alcune app built-in all’interno del device (Figura 8.7).

Questo momento è molto importante e devono essere chiare al team di sviluppo tutte le funzionalità di terze parti che vogliamo utilizzare all’interno della nostra applicazione. Il bundle è necessario per iniziare a sviluppare l’app e per fare i test su iOS in fase di sviluppo e ha conseguenze su tutto il provisioning dell’applicazione.

Figura 8.5 – Il primo step per la pubblicazione di un’app, ma ciò che bisogna fare all’inizio del progetto tecnico è la creazione dell’iOS app Bundle ID.

Figura 8.6 – App ID suffisso.

Figura 8.7 – Scelta dei servizi avanzati di Apple.In servizi principali possibili sono:

•Livello di protezione dei dati dell’app: in questo modo potete decidere se utilizzare il sistema di criptazione dei dati di Apple per il contenuto della vostra app. Attivando questo servizio e selezionando i differenti livelli di protezione i dati della vostra app non sono accessibili da terze parti in modo completo, oppure quando l’app è aperta e attiva o ancora quando il dispositivo è stato sbloccato e l’utente ha fatto una prima autenticazione. Più è sensibile il contenuto della vostra app, per esempio per gran parte di software in ambito medicale, e maggiore deve essere il livello di protezione dei dati stessi.

•Game Center: nel caso in cui la vostra app sia un gioco oppure abbia al suo interno uno schema di gamifcation, potreste valutare molto caldamente l’ipotesi di collegamento col sistema centrale di gioco di Apple: questo vi permette di evitare un eventuale login all’utente in un altro sistema di multi player e potete confgurare molto velocemente classifche e sfde tra giocatori. Infne la piattaforma è un piccolo canale distributivo e di marketing parallelo allo store: gli “appgiocatori” guardano le classifche e stringono amicizie virtuali con altre persone e possono vedere a quali giochi ha giocato un altro utente. Essere nel Game Center può quindi anche stimolare i download dell’app stessa.

•ICloud: la possibilità, come già accennato, di interfacciarsi con la nuvola di casa Apple.

•In-app purchase: è fondamentale che fn dall’inizio abbiate chiaro il vostro modello di business e quindi anche la presenza o meno di acquisti all’interno della vostra applicazione, perché dovete comunicarlo a Apple fn dalla creazione del progetto.

•Inter-app Audio: nel caso in cui la vostra app abbia a che fare con la musica, ma anche audio di qualsiasi genere che vi interessa rimangano attivi anche mentre il vostro device è bloccato oppure con l’app in background, dovete scegliere assolutamente questa opzione.

•Passbook: se volete sfruttare il servizio di geolocalizzazione e di biglietto virtuale, la scelta di Passbook è pressoché obbligatoria. Molte app turistiche, ma anche di servizi di trasporto, utilizzeranno sempre di più questo sistema precostruito che permette la creazione di biglietti elettronici sicuri e offre dei servizi avanzati di prossimità molto interessanti e, per molti versi, ancora inesplorati. Potete comunicare con un vostro utente quando questi è vicino a un determinato luogo: un aeroporto, una stazione, una via con tanti hotel… Siamo solo all’inizio.

•Push Notifcations: creare le notifche in push vi permette di avere un collegamento con tutti gli utenti che hanno installato la loro app e hanno permesso al dispositivo di inviare notifche di tipo push. Abbiamo già ampiamente parlato dell’argomento e dei vantaggi molto importanti delle notifche: non lasciatevi sfuggire questo canale marketing e di relazione con chi utilizza il vostro software e selezionate quindi questa opzione.

Una volta scelti tutti i servizi avrete finalmente completato il bundle ID e potete quindi procedere con il primo vero step di app marketing e comunicazione.

Scelta del nome ed elementi base dell’app.

Il primo step di questa fase è l’inserimento delle informazioni di base della vostra applicazione: la lingua di base dell’app (a prescindere dal numero di lingue in cui la sviluppate, scegliete l’italiano se avete questa lingua oppure l’inglese). Apple smista anche la fase di review in base a queste informazioni.

Figura 8.8 – Lo step iniziale, dopo aver creato il bundle ID, per generare una nuova applicazione all’interno dell’Apple App Store (APP INFORMATION).

Dovete quindi inserire il nome della vostra app, e in questo modo lo bloccherete per 180 giorni. Questo è il nome con la quale comparirà all’interno del negozio. Dovete dare un nome vostro interno univoco all’applicazione che viene considerato come un ID da voi attribuito da parte di Apple: viene definito, come in molti altri campi, Numero SKU. Infine dovete associare il bundle iOS ID che avete precedentemente creato con la fase 1.

A questo punto procederete alla fase della Figura 8.9 dove dovrete scegliere il nome dello sviluppatore o dell’azienda con il quale comparire sullo store, così come selezionare la categoria, l’eventuale sottocategoria e, a seconda dei casi, anche una sotto categoria secondaria.

Infine, dovete dichiarare la fascia di età per cui è adatta la vostra applicazione, tutte informazioni che avete già pronte dato che abbiamo già fatto la launch checklist e controllato che fosse tutto presente.

Inserimento dei metadata.

Passiamo quindi alla compilazione vera e propria della scheda della vostra applicazione, che sarà visibile agli utenti, l’immagine iniziale della vostra applicazione, il packaging intangibile ma fondamentale del vostro software.

Figura 8.9 – Inserimento dei dati di base dell’app riferiti alla singola versione. I dati selezionati non possono più essere modificati fino a un aggiornamento dell’app stessa, come mostrato in questa figura.

Figura 8.10 – La sezione di inserimento dei metadata compilata.

Dovete curare scrupolosamente i contenuti di questa sezione come già abbondantemente spiegato. Qui comincia la comunicazione e il marketing a supporto del vostro prodotto: non dimenticatelo mai e fatelo professionalmente. La sezione dei metadata va compilata per ogni lingua: maggiori sono le lingue che presentano il vostro software, maggiori chiaramente sono le possibilità di download a livello globale. Non pensiate che facendo la scheda dello store in venti lingue con l’app solo in una possa aiutare con un moltiplicatore di venti; però qualcosina aiuta.

Bisogna inserire la descrizione completa dell’app, la descrizione dell’aggiornamento per ogni versione che viene pubblicata (chiaramente non per la 1.0) e il campo delle keyword che è fondamentale per comparire nelle ricerche dell’Apple App Store. Infine vengono richieste le url di supporto e della privacy, obbligatorie, e quella opzionale della comunicazione e del marketing della vostra app o dell’azienda che sta facendo comunicazione attraverso un software.

La seconda sezione dei metadata prosegue con la parte più visuale della scheda.

Figura 8.11 – La sezione degli screenshot dell’Apple App Store.

Apple richiede diversi formati degli screenshot che aumentano chiaramente nel caso di pubblicazione per iPad o per iPhone in entrambe le versioni delle dimensioni dello schermo. Ci siamo già abbondantemente dilungati sull’importanza delle immagini della scheda dell’app, quindi dovremmo avere già tutto pronto.

Figura 8.12 – La sezione delle informazioni di contatto e di supporto di Apple App Store.

Una volta compilate le sezioni dei metadata nelle varie lingue, siete pronti per caricare i file della vostra app.

Uploading del codice compilato.

La parte tecnica del team di sviluppo avrà già predisposto i dati compilati e protetti a livello di codice. Tutto è pronto quindi per caricare il pacchetto sui server di Apple… Il sipario ancora non si è aperto, ma si sente già il rumoreggiare del pubblico nel foyer.

A questo punto la vostra app ha già passato la fase “waiting for upload” e, poco dopo la fine del caricamento del file compilato, riceverete una notifica che porterà l’applicazione nello stato di “upload received”; la vostra app dovrebbe diventare pochi istanti dopo “ready for review”.

Figura 8.13 – Le fasi di pubblicazione di un’app nell’Apple App Store.

Questa è la fase più lunga di tutto il processo di sottomissione e la più noiosa; non dovete fare nulla, tranne il team di supporto all’app che invece starà lavorando freneticamente, ma solo aspettare che Apple verifichi manualmente la vostra app e l’approvi. Attualmente, i tempi di attesa variano da sei a otto giorni lavorativi, dopodiché l’app entra nella vera e propria fase cruciale “in review”. A questo punto, incrociate le dita: è in questo momento che stanno testando il vostro software. Nel caso in cui non riceviate entro alcune ore nessun aggiornamento, le probabilità che la vostra app venga respinta crescono mano a mano che passa il tempo. Se tutto va bene, come spesso accade, dopo 5-7 ore dovrebbe assumere lo status di “processing for app store”; questo significa che l’app è stata approvata, ma deve essere ancora caricata nel negozio… Tempo una decina di minuti e finalmente saremo sugli scaffali virtuali e l’app diventerà quindi “ready for sale”. Ci siamo, lo spettacolo comincia.

Il processo di sottomissione di Google Play

I materiali necessari per la fase di submission di Google Play sono in pratica gli stessi visti nei paragrafi precedenti, quindi cambia il processo, ma non cambia la sostanza. Google offre, a mio giudizio, un sistema molto più elaborato, ma nel contempo più funzionale a tutte le fasi dello sviluppo dell’app stessa.

Il sistema si divide sostanzialmente in quattro fasi ben distinte:

Setup.

Sviluppo.

Debugging e Testing.

Pubblicazione.

Setup: pariteticamente a quanto avviene per il mondo Apple, in questa fase gli sviluppatori devono scaricare tutti i software necessari per creare le app in ambiente di sviluppo Android e iscrivere la propria azienda come sviluppatore di Google Play. Gli sviluppatori creeranno anche il cosiddetto “provisioning” per i dispositivi mobili sui quali vorranno installare le app nella primissima fase di sviluppo del progetto.

Sviluppo: durante questa fase prettamente tecnica, il team dei programmatori costruirà il progetto all’interno della piattaforma di sviluppo implementando il codice sorgente, associando le librerie di cui avrà bisogno la vostra app e creando il file Android Manifest.

Debugging e Testing: per sottolineare quanto sia importante questa fase nella creazione di un’app, e per facilitare il beta testing allargato per i progetti più importanti, Google dedica una vera e propria sezione a questo momento molto importante per l’app. Google la mette così a disposizione degli sviluppatori attraverso il proprio social network, Google Plus, al quale, nel bene o nel male, chiunque è ormai “obbligato” a iscriversi, rendendo molto più agevoli, rispetto al mondo iOS, il contatto, il coinvolgimento e il passaggio dell’applicazione in fase di test.

Figura 8.14 – Google sottolinea l’importanza dei testi di usabilità conducendo gli stessi sviluppatori, attraverso la propria piattaforma di pubblicazione, a passare attraverso una fase Alpha e una fase Beta[56].

Pubblicazione: una volta completati tutti i processi precedenti si può cominciare a creare un’app. Il materiale della launch checklist dev’essere tutto pronto in tutte le lingue per le quali si intende pubblicare l’app.

Anche in questo caso l’ottimizzazione del contenuto della scheda è di fondamentale importanza per ottenere successo all’interno dello store. Gli elementi testuali di base di un’applicazione, oltre a quello della lingua a monte, sono il nome, lungo al massimo trenta caratteri, la descrizione di 4.000 battute e il testo promozionale di 80 caratteri. A differenza di Apple, non esiste una stringa di campo keywords, mentre c’è una descrizione breve. I processi sono simili, ma queste piccole differenze fanno già comprendere la diversità a livello di posizionamento all’interno dei rispettivi motori di ricerca dei due negozi.

Figura 8.15 – La parte testuale e descrittiva della scheda dello store.

La parte visuale di gestione della scheda è molto simile a quella iOS e permette fino a otto screenshot (o meglio immagini) e ne impone un minimo di due. La sezione è divisa tra immagini per gli smartphone e i tablet da 7 e da 10 pollici, perché Google Play cambia a seconda del dispositivo utilizzato (Figura 8.16).

Oltre alle immagini di base, Google Play richiede anche il materiale promozionale di corredo della vostra app come l’icona in alta risoluzione, il banner in primo piano, utilizzato eventualmente dalla redazione nel caso di posizionamento privilegiato all’interno dello store e un’immagine promozionale che potrebbe essere usata anch’essa nelle varie sezioni che dispone il negozio di app. A differenza di Apple, Google permette anche di associare un video promozionale della propria app, una caratteristica molto interessante per gli utenti e per gli sviluppatori, in quanto un video permette certamente di capire meglio come funziona un’app o come sia la sua grafica rispetto a delle immagini o a un testo. Si noti come il video debba essere prima inserito dagli sviluppatori sulla piattaforma di YouTube, perché in realtà lo store richiede semplicemente una url della propria piattaforma video. Una mossa strategica molto interessante quella dell’azienda di Page e Brin. Con questa semplice “scorciatoia”, hanno creato la tv mondiale più importante di trailer di applicazioni, un posizionamento che per alcuni potrebbe sembrare una nicchia, ma che genera milioni di visualizzazioni di video quotidiane su questo argomento. Vista inoltre la tendenza, avrà un’audience enorme e in espansione, con una raccolta pubblicitaria di altre app concorrenti molto interessante in una prospettiva futura. E tutto con un semplice “add URL”.

Anche qui viene chiaramente richiesta la categorizzazione della propria app secondo lo schema già visto delle categorie dello store e il rating sui contenuti, che è molto più semplificato rispetto a quello della casa di Cupertino (Figura 8.18).

Figura 8.16 – La parte visuale dell’app per l’inserimento delle immagini dell’applicazione nei diversi formati.

Figura 8.17 – Il materiale promozionale a supporto dell’app e il video pubblicato naturalmente su YouTube.

Figura 8.18 – Categorizzazione primaria e secondaria all’interno dello store Google Play e rating dei contenuti della propria app.

Infine, parallelamente a come avviene per Apple, la scheda si chiude con gli elementi di contatto e della privacy della propria applicazione.

Figura 8.19 – Creazione dei contatti e del link alla privacy della propria app in Google Play.

In entrambi i casi abbiamo visto che i processi sono molto simili. Le due piattaforme evolveranno certamente in futuro e le fasi descritte potrebbero essere anche già diverse mentre state leggendo questo libro. Tuttavia, quello che dovete aver compreso bene sono le linee guida principali e soprattutto il fatto che dovrete arrivare ben preparati al momento della pubblicazione del vostro progetto. Non vi deve essere sfuggito nulla; i pannelli che vedete adesso devono essere già stati studiati a fondo. Dovrete aver segnato con una bella riga rossa tutto il materiale a disposizione della vostra checklist. Avete tutto? Bene, siamo pronti per il viaggio. Allacciamo le cinture, ma non partiremo immediatamente. Per Apple ci vogliono circa sette giorni, su Google Play un paio e anche meno: aspettiamo, prepariamo tutto per il lancio e per il supporto… è la quiete prima della tempesta!

56. Avevo già scritto il capitolo sui test di usabilità quando Google Play ha introdotto questo nuovo modello di pubblicazione.

CAPITOLO 9

MARKETING DELLE APPLICAZIONI

Creazione della comunicazione parallela

Il momento del lancio dell’applicazione è sempre emozionante: quando finalmente il vostro prodotto arriva sugli scaffali del negozio mondiale di app siamo solo all’inizio della corsa dopo mesi di allenamenti. Chi investe nella creazione dell’app dovrebbe sempre chiedere agli sviluppatori, fin dall’inizio, che budget allocare al supporto del progetto una volta lanciato e con un orizzonte temporale di almeno sei mesi, meglio ancora se un anno. Il mio consiglio personale è di investire da un minimo del 30% fino al 50% dell’intero progetto nel marketing del vostro software. Sostanzialmente per un’app dove il team di sviluppo costa in totale 10.000 euro, dovreste immaginare di stanziare un budget totale di realizzazione pari a 15.000 euro come minimo: ne utilizzerete 10.000 per sviluppare l’app e 5.000 per il marketing e la comunicazione della stessa. Alternativamente, per un software il cui costo di sviluppo è sempre di 10.000 euro potreste decidere anche di allocare una cifra equivalente per il marketing dell’app. Quando parlo di questi costi, intendo sia il lavoro per lo sviluppo della comunicazione di base, sia una porzione da investire in campagne pubblicitarie direttamente.

Abbiamo già visto come il team di supporto può anche essere distinto rispetto a quello di sviluppo. Chiaramente le due parti devono avere un dialogo e un rapporto continuativo: prima, durante e dopo la creazione, ma possono essere anche due aziende distinte, come spesso accade, dato l’elevato livello di specializzazione che sta raggiungendo il mercato.

Esiste un set di materiale minimo a disposizione che il gruppo di supporto dovrebbe produrre alcuni elementi molto importanti per tutto il supporto del prodotto come il nome stesso, il logo, gli screenshot e la descrizione sono obbligatori per la pubblicazione e, come visto in precedenza, fanno parte anche della launch checklist. Per un supporto completo dell’app nell’ambiente digitale, vi consiglio vivamente di aggiungere anche altri canali di comunicazione oltre alla sola scheda all’interno degli store. Anche il team dedicato al marketing e alla comunicazione dovrebbe avere una propria lista di lancio e molte di queste attività dovrebbero essere continuative anche dopo il lancio dello store, sperando che possano durare per anni, segno di ampio successo dell’applicazione.

Materiale minimo per il supporto:

Nome e Logo.

Screenshot.

Descrizione e Keywords.

Video.

Sito web/sezione sito/blog.

Social media.

Newsletter e press kit.

Nome e Logo: due elementi di base della vostra idea. Abbiamo già parlato di come creare dei nomi accattivanti e dei limiti in termini di lunghezza, così come analizzato la realizzazione di un’icona dell’app che possa distinguersi da quella delle concorrenti. In questa fase i due elementi dovrebbero essere chiari e ben stabiliti.

Screenshot: le immagini della vostra app sono un elemento chiave per comunicare al pubblico il vostro progetto e presentarlo in modo visuale. Vedremo nell’ASO (Application Store Optimization) come utilizzarle al meglio. Dovrete comunque disporre possibilmente di molti più screenshot di quelli richiesti dallo store, dovrete utilizzarli in tutti i canali a disposizione ed è molto meglio avere già a disposizione una buona mole di materiale.

Descrizione e Keywords: anche di questi elementi che risultano decisivi ne parleremo nel prossimo paragrafo relativo all’ASO.

Video: vi consiglio di creare almeno un video della vostra applicazione, soprattutto nel caso in cui la rendiate disponibile anche in Google Play dove potete, come visto, inserirla all’interno della scheda dell’app. Create comunque un video anche se doveste sviluppare solo per iOS; è utilissimo all’interno del sito web o della sezione dedicata all’app, perché spiega in poco tempo e in modo poco impegnativo per l’utente i punti di forza del vostro software. Inoltre, un canale su YouTube e la presenza dell’app all’interno della web tv leader mondiale di trailer e video di app è un ulteriore canale di comunicazione e di marketing che potete e dovete sfruttare. Esistono sostanzialmente due tipologie di video che potete realizzare per supportare la vostra applicazione: video app emozionali oppure video app demo. La prima tipologia richiede uno sforzo e un impegno sicuramente maggiori, ma, per determinate categorie di applicazioni come i videogiochi, potrebbero essere determinanti. I video app emozionali presentano l’applicazione con un video normalmente di quindici o trenta secondi, ma ci sono casi anche di un minuto e più, dove esiste un vero e proprio montaggio video normalmente composto da grafica e da registrazioni dell’app in azione, con scritte, slogan, musica e, raramente, parlato. In sostanza sono dei veri e propri trailer di applicazioni a tutti gli effetti, simili a quanto avviene ormai da anni nel mondo dei videogiochi. Molto spesso, questa tipologia di video viene utilizzata anche all’interno di video banner o di formati cosiddetti “rich media” come messaggi promozionali dell’applicazione dentro le piattaforme per inserzionisti.

Figura 9.1 – Un esempio, con alcuni fotogrammi, di video emozionale che pubblicizza Clash of Clans.

La seconda tipologia di video è molto più semplice ed economica da realizzare e alla portata di chiunque e consiste sostanzialmente in un montaggio di una o più registrazioni video dell’app in azione; essa presenta eventualmente delle aggiunte testuali durante il video o, nei casi più artigianali, la voce dello stesso sviluppatore che spiega il funzionamento del proprio software. Nel caso in cui decidiate di intraprendere questa strada, che si adatta molto bene ad alcune tipologie di app, come quelle per utilizzo professionale o per le app che presentano alcuni livelli di complessità, vi consiglio vivamente di farlo con una parvenza di professionalità. Esistono molti strumenti gratuiti di montaggio e alcuni dedicati espressamente alla creazione di demo per applicazioni. Vi prego di registrare la sessione video dello smartphone e del tablet e di aggiungere gli effetti del tap con svariati software gratuiti. Non registrate mai le vostre dita che armeggiano sul dispositivo mobile, magari con la vostra voce in sottofondo in un inglese maccheronico. I vostri video verranno visti solo per alcuni secondi e quasi tutti gli utenti li abbandoneranno dopo pochissimo tempo. Darete solo un’immagine molto artigianale di voi stessi e, di conseguenza, della vostra applicazione. Nel bene o nel male, anche l’abito ha il suo peso e il suo valore nella comunicazione e nel marketing.

Figura 9.2 – Un esempio di video app demo dell’applicazione: Type in Walk. Il video fa vedere subito l’utilità dell’app e come funziona. Posso scrivere un messaggio mentre ho la camera del dispositivo attiva, in modo da vedere durante l’immissione del testo dove sto andando fisicamente. Un video è perfetto per far capire immediatamente le funzionalità dell’app.

Infine, potete pensare di intraprendere una via alternativa: potete decidere di spiegare in pochi secondi la vostra app, facendola vedere in azione quasi come se fosse una demo e aggiungendo qualche tocco ed effetto grafico e un’ottima colonna sonora per ottenere una soluzione che spieghi ed emozioni al tempo stesso. Non uno spot e non una demo, niente di eccezionale, ma nemmeno di artigianale come una registrazione dello schermo e soprattutto molto più economico della prima tipologia. Cercate tra i grafici che collaborano già con voi: molto probabilmente troverete chi ha le capacità per realizzare questa forma ibrida di comunicazione video. È il caso di Methodic, widget realizzato per Android che suggerisce l’applicazione giusta nel momento giusto, in modo del tutto personalizzato e in base alle abitudini dell’utilizzatore dell’app.

Figura 9.3 – Alcuni fotogrammi del video del widget Methodic: un video emozionale che fa vedere contemporaneamente il funzionamento dell’app.

Sito web/sezione sito/blog: è necessario creare una vera e propria base di appoggio di tutta la comunicazione digitale. Questa attività si concretizza nella realizzazione di un sito web dedicato, che possa spiegare, in modo molto più approfondito rispetto alla scheda dell’app presente negli store, tutto il vostro software. A differenza di altri canali di comunicazione, dove spesso utilizzerete piattaforme di terze parti (lo store, i social network), avete completamente il controllo di qualsiasi elemento del vostro sito: grafica, impaginazione, link; tutto è gestibile direttamente e modificabile in modo continuativo. Nel caso di creazione di un’applicazione con un modello di business sinergico alla comunicazione aziendale, dovete necessariamente costruire una sezione ad hoc all’interno del sito web dell’organizzazione e sfruttare la presenza di utenti attivi per veicolarli verso il download dell’app. Per i progetti con maggiore contenuto testuale e per mantenere i costi contenuti, potete anche pensare di utilizzare una piattaforma per il blogging open source e gratuita per spiegare e comunicare il vostro progetto. In qualsiasi caso, dovreste assolutamente avere delle pagine web gestite direttamente da voi che presentino la vostra app in modo completo e approfondito. Il sito web per app (o la sezione dedicata o il blog dell’app), oltre a creare un’immagine più completa della vostra applicazione, deve tenere conto come minimo di due obiettivi distinti:

Veicolare gli utenti verso la/e scheda/e degli store per il download.

Fornire assistenza e supporto ai clienti.

Veicolare gli utenti verso la/e scheda/e degli store per il download: il sito web deve convincere gli utenti a scaricare la vostra app, informando, coinvolgendo ed emozionando ove necessario. Avete costruito queste pagine web non fini a se stesse, ma per incrementare il numero di download all’interno dello store. Le pagine devono contenere costantemente i link a quelle degli store dove avete pubblicato l’app; il vostro obiettivo primario è quello di canalizzare il traffico qualificato verso gli store, a un clic dal download dell’app. Vi consiglio vivamente l’utilizzo dei cosiddetti badge dei negozi di applicazioni. Questi elementi grafici sono forniti direttamente dagli app store ai propri sviluppatori (ma volendo sono accessibili a chiunque) e rappresentano ormai una simbologia standard per tutti gli utenti i quali comprendono immediatamente che, cliccando (o tappando) quell’elemento grafico, verranno diretti verso la scheda dell’app nel negozio.

Figura 9.4 – I badge degli app store: Apple Store, Google Play e Microsoft Marketplace.

Quando lavorate in un ambiente digitale e avete un obiettivo, dovete misurarlo: se non lo fate state sbagliando completamente l’approccio ai nuovi media. Uno dei maggiori vantaggi che ha portato la rete è la possibilità di misurare e di avere dei calcoli del ritorno sull’investimento molto più precisi rispetto a prima. Purtroppo, gli store forniscono poche informazioni della vostra app e soprattutto attualmente non danno alcun dato relativo alla vostra scheda all’interno del negozio di applicazioni. Non sapete quante visite ha ricevuto quella pagina, né tantomeno per quanto tempo o in termini di utenti unici, se sono stati sfogliati gli screenshot, quanti hanno aperto la pagina delle recensioni e così via. Non sapete nulla e questo è un forte limite per l’analisi e l’ottimizzazione in termini ASO. Purtroppo, la pagina dell’app sullo store non è sotto il vostro controllo, non potete inserire nessun tag per la sua misurazione; pertanto, quali e quante informazioni ricevete al riguardo sono una scelta e una decisione non sotto il vostro controllo. Attualmente, gli store hanno deciso di non fornire la benché minima informazione al riguardo, sbagliando, dal mio punto di vista, e perdendo anche una certa quota di fatturato. Sul sito web dell’app potete invece misurare tutto quello che volete; l’obiettivo del sito è quindi quello di spostare traffico verso la scheda del negozio dove l’utente può fare il download. La misurazione di questo obiettivo fondamentale è molto semplice: qualsiasi software di web Analytics vi permette di appendere un codice (normalmente una funzione Javascript) a qualsiasi link voi facciate che porta il browser dell’utente all’esterno del proprio sito web sia verso altri siti Internet, sia nel caso di comandi per aprire altre app all’interno dei device. Posso quindi sapere quanti browser hanno cliccato i link che posizionate, sostanzialmente e indirettamente, quanto traffico avete spostato e avvicinato al download. L’equazione ideale a cui tendere è quella che ho battezzato “equazione del triplo cento”:

100 Utenti Unici Assoluti Sito web = 100 Clic su link allo store = 100 app Download

Più vi avvicinate a un rapporto del genere, maggiore sarà il successo della vostra app. Questa situazione non è sempre così rosea e nella realtà dei fatti avrete probabilmente uno scenario con il secondo e il terzo valore molto inferiori al primo. Dovete sempre misurare i rapporti e soprattutto analizzare come cambiano nel corso del tempo e, fondamentale, come sono influenzati dalle piccole modifiche che dovreste apportare periodicamente seguendo il modello del processo di miglioramento continuativo.

Fornire assistenza e supporto ai clienti: il secondo obiettivo classico di un sito web per app è quello di fornire supporto a chiunque vi contatti e cercare quindi di entrare in contatto diretto con gli utilizzatori della vostra applicazione. Non solo per problemi e assistenza di carattere tecnico, ma dovete stimolare gli utenti a lasciarvi giudizi, impressioni e suggerimenti. Non smetterò mai di ripetere quanto sia fondamentale ascoltare con massima attenzione la voce dei vostri utenti. La misurazione di questo obiettivo è molto semplice: veicolate qualsiasi invio lato utente attraverso form sulle pagine web, evitando l’utilizzo della mail diretta. Settate un punto di conversione non monetaria ogni qualvolta il form viene compilato e un tag Javascript avanzato sulla pagina di ringraziamento in seguito alla compilazione del form. In questo modo avrete tutte le informazioni approfondite degli utenti con i quali avete avuto un maggior engagement. Ricordate che questo tipo di utilizzatori, cioè quelli con cui entrate in contatto, sono i primi “strumenti di marketing” della vostra app e, a volte, sono meglio di qualsiasi campagna pubblicitaria.

Figura 9.5 – Il form di richiesta informazioni e di contatto dell’app Gambalunga e il Pirata Senzanaso.

Per spiegare nel dettaglio come realizzare un sito web ci vorrebbe un altro libro; sappiate che ci sono alcune linee guida di base che dovreste seguire:

Il nome del dominio dovrebbe coincidere con il nome dell’app: abbiamo già parlato abbondantemente della scelta del nome. Quando la state facendo verifcate che il dominio corrispondente sia ancora disponibile, almeno con un suffsso internazionale (consiglio il .com) e anche con quello nazionale nel caso di app con un forte attaccamento geografco. Per “giocare un po’ sporco”, potreste pensare di aggiungere le tre lettere app al dominio stesso. Così per la mia app “Zanzo” registrerò www.zanzo.com, ma potrei osare anche www.zanzoapp.com o www.appzanzo.com o ancora www.app-zanzo.com.

Fate vedere l’app sullo smartphone o sul tablet: non usate solo immagini e grafca dell’app scollegate dal dispositivo; fate capire immediatamente e visivamente di che cosa state parlando e usate quindi degli screenshot montandoli sul dispositivo vero e proprio. Implementate vicino a questi il badge come “call to action” verso il download dell’applicazione (Figura 9.6).

Usate i video, collegate i canali sociali: il vostro sito web deve essere l’hub di tutta la comunicazione: inserite il o i video che avete realizzato già in primo piano, collegando tutti i social dove siete presenti ed eventualmente embeddando il contenuto o porzioni di esso all’interno del sito (Figura 9.7).

Figura 9.6 – Il sito dell’app Gambalunga e il Pirata Senzanaso: gli screenshot sono montati sui dispositivi a livello grafico e non trattati come delle semplici immagini.

Figura 9.7 – La homepage dell’app Methodic presenta il video immediatamente in primo piano e i link ai canali social.

SEO, SEO e ancora SEO (ma non era morto?): le vostre pagine web devono attrarre traffco qualifcato e potenzialmente interessato alla vostra applicazione. Le pagine devono essere ottimizzate alla perfezione e tenere conto sempre, rispetto a un sito tradizionale, delle parole chiave di base come “app, applicazione, apps, applicazioni ecc.” ed essere correlate alla categoria e all’utilizzo. Gli utenti sui motori di ricerca web, a differenza di quanto avviene su quelli app, fanno delle ricerche molto specifche quando cercano un software per il loro dispositivo mobile. Pensate sempre anche a parole chiave dalla cosiddetta “coda lunga”, frequenti per questa tipologia di siti web, come “app per comprare viaggi aerei” oppure “app biglietti aerei” “applicazione biglietteria aerea”. Tutto ciò per sottolineare come sia importante comprendere il contesto e le motivazioni di ricerca di un utente. Anche in questo caso servirebbe un libro solo per spiegare queste tecniche. Il posizionamento di un sito web per app dipende molto dal numero di concorrenti, dalla categoria e in generale dalle fnalità dell’app stessa. Affdatevi a persone professionali, molto probabilmente gli stessi che hanno realizzato il mini-sito; nel caso di sviluppo all’interno, ove mancassero competenze specifche, fatevi fare una piccola consulenza una volta che avete pronto il sito web, almeno sulla correttezza del codice e della SEO on page e della semplicità di spidering da parte dei robot dei motori di ricerca.

Gestione delicata e puntuale degli User Agent: abbiamo già parlato abbondantemente dell’importanza nel riconoscimento corretto degli User Agent[57]. Riconoscere correttamente questi elementi tecnici è importantissimo per qualsiasi sito web, ma acquista un valore ancora più importante e fondamentale per i siti dedicati a un’applicazione. Mentre se navigo un sito app da desktop verrò ridiretto sulla piattaforma dello store e scaricherò l’app che dovrò successivamente installare sul dispositivo sincronizzandolo, lo stesso link (del badge) visualizzato da un tablet o da uno smartphone apre direttamente l’app dello store sul dispositivo e la installa immediatamente. Le visite da dispositivi mobili su siti web delle app sono quindi molto più vicine al processo di conversione, ovvero al download del nostro software; per questo motivo possiamo pensare, per chi naviga il nostro sito web da mobile, di utilizzare delle tecniche leggermente più invasive verso l’utente. Quando il mio server “sente” di essere consultato da un device di questo genere potrebbe far comparire per qualche secondo un banner che punta alla pagina dello store cercando di “forzare” un po’ la mano al nostro navigatore, ma solo a quello che ha già in mano il dispositivo sul quale vorremmo ci fosse la nostra app. Il riconoscimento dello User Agent è ancora più importante per tutte le app che vengono distribuite su più store contemporaneamente perché sviluppate per più piattaforme. È inutile tempestare di banner per l’Apple App Store tutti gli utenti Android che navigano sul vostro sito e viceversa, così come potrei decidere di essere più invasivo sui tablet rispetto agli smartphone, perché la mia app si adatta meglio ai primi. Capire chi sta guardando e interagendo coi nostri contenuti, perlomeno a livello di sistema operativo e dimensione dello schermo, è fondamentale ed essenziale per un supporto completo del sito web.

Figura 9.8 – La sezione dedicata all’app del sito Otto Chocolates: avendo sviluppato un’app gioco, l’azienda fa comparire un banner a scomparsa nella porzione bassa dello schermo a coloro che arrivano sul sito e lo navigano con il tablet. Chi vi accede dal desktop invece non vede nulla.

Social media: aprite gli account sociali a supporto dell’app, sia sui social principali sia nei social di nicchia, nel caso in cui la vostra app si rivolga a un pubblico specifico che ha social specifici. Siate attivi e coinvolgete gli utenti, sfruttate il tempo reale di queste piattaforme spostando il supporto ai clienti e accettando, anzi stimolando, suggerimenti, commenti e opinioni: ascoltate, interagite, coinvolgete. Andare sui social vuol dire essere sociali: non chiudetevi in voi stessi e non siate autoreferenziali: otterrete l’effetto opposto. Qui stiamo parlando dei canali sociali dell’applicazione, mentre dovreste aver già integrato coi social network l’app in modo che i vostri utilizzatori possano godere della socialità durante l’applicazione. Cercate di intercettare questi scambi social, soprattutto quelli degli influencer, inserendovi in modo intelligente nelle loro conversazioni, e rispondendo in maniera costruttiva a chi fa recensioni di app e ai blog sulla tecnologia mobile in generale. Insomma, cercate di fare emergere la vostra voce e fatevi aiutare da tutte le vostre interazioni sociali per fare un po’ di “ronzio”: attivate il social buzz. Per le app video ludiche, ma in generale per quelle più leggere (quiz, test ecc.), un’idea molto interessante potrebbe essere quella di lanciarle anche come Applicazioni all’interno di Facebook. Candy Crush Saga è nata prima sul social network di Zuckerberg e solo dopo ha spopolato anche negli app store, ma la spinta iniziale enorme l’ha data Facebook. Questa tipologia di applicazioni (pensate anche a Ruzzle) ha un rapporto fortissimo, quasi intrinseco con i social network stessi, e il Facebook Connect che richiede fa parte integrante di tutta la strategia di comunicazione virale che è stata progettata a tavolino.

Figura 9.9 – La pagina di Facebook di Candy Crush Saga: potete giocare direttamente anche sul social network e poi continuare i livelli “delirio” di questo gioco dal vostro dispositivo mobile.

Newsletter e press kit: infine, dovreste disporre di uno strumento di mailing anche rudimentale; non serve a nulla inviare spam a destra e a sinistra. Usate sempre le vostre liste mail con utenti che avete coinvolto nel corso del tempo. Non consiglio di comprare liste mail e fare mail marketing incondizionato, perlomeno non nella fase iniziale. Lo strumento per la gestione e l’invio delle mail è molto utile invece nella prima fase di lancio e, per i progetti più ampi, anche nel momento del Beta testing. Abbiamo già parlato del reclutamento dei Beta tester. Inoltre, poiché ognuno di noi ha amici e familiari che possiedono un dispositivo mobile, chiedete loro un consenso esplicito (anche online) e, una volta ottenuto, mettete in un file .xls o in una tabella di un database le sue informazioni, sostanzialmente come già fatto nella fase di Beta. Al momento della pubblicazione avrete quindi già questi file e tutti i contatti; nel caso in cui siate sviluppatori, nel corso del tempo andrete piano piano ad aumentare le dimensioni di queste liste (attenzione, coinvolgendo gli utenti non comprando mail e spammando). Nel momento in cui ricevete la mail dallo store che vi notifica che la vostra app è pronta per la vendita o il download, dovreste inviare una mail, preparata con largo anticipo, possibilmente con delle varianti a seconda del rapporto con il destinatario. Quindi parliamo di una mail molto informale, amichevole e con delle richieste anche un po’ più esplicite per colleghi, parenti e amici stretti e magari una un po’ più formale e con richieste meno esplicite per i Beta tester con i quali si ha un rapporto minore. La mail dovrebbe essere una sintesi del Press Kit, ovvero di una cartella di materiale informativo e promozionale da inviare a giornali, radio, blog, tv e web tv: ricordatevi che state lavorando in un settore che fa molto “tendenza” e che spesso gli editori hanno bisogno di notizie fresche e trendy da pubblicare e da raccontare; non crediate che i giornalisti o i blogger importanti siano alieni che vivono su un altro pianeta, irraggiungibili. Intercettateli sui social, inviate mail formali e ben congegnate, creando un comunicato stampa conciso, semplice e moderno. Anche in questo caso, usate la tecnica del Pitch Elevator dell’ASO, con i blogger e i siti di recensioni che sono sommersi da decine di app quotidianamente. Facilitate loro la vita facendo cogliere in pochissimo tempo i punti di forza e di debolezza della vostra app: catturerete così molto di più l’attenzione con pochissime parole e due immagini che non con un PDF da 12 pagine in cui si spiega nel dettaglio il vostro software. Una volta pubblicata l’app, inviate la mail e chiedete, più o meno esplicitamente, il download dell’app, dicendo che anche se non la usano può aiutare e servire molto alla vostra app per il suo posizionamento (terrei queste considerazioni solo con la lista dei destinatari più ristretti). Chiedete anche, nel caso di apprezzamento del lavoro, di essere così gentili da lasciare un giudizio ed eventualmente una recensione. Non siate troppo espliciti: meglio non ricevere nemmeno una recensione che, dopo aver stressato l’interlocutore con quindici mail, ottenerne una con un giudizio pessimo. Anche sul mail marketing si potrebbe scrivere un libro; il mio consiglio è di utilizzare le mail per il lancio in quanto è un momento decisivo per innescare la viralità della vostra applicazione.

ASO on-app: la SEO on-page delle app e ottimizzazione della scheda dello store

L’acronimo ASO, coniato solo da qualche anno, indica i termini inglesi di ottimizzazione dell’applicazione all’interno dello store: Application Store Optimization. Per chi mastica digitale è l’equivalente della SEO (Search Engine Optimization) dei siti web per il mondo delle applicazioni. Il parallelo è molto azzeccato e, personalmente, mi spingo anche oltre. Il posizionamento di un sito web deriva da una moltitudine di variabili che possiamo distinguere in due macro tipologie: variabili derivanti da come è strutturato il sito web e il codice Html delle pagine, cosiddetto SEO on-page, e variabili derivanti da caratteristiche esterne, e più o meno influenzabili, al sito web, il cosiddetto SEO off-page. Possiamo mantenere questo parallelo anche per l’ASO; ho quindi deciso di distinguere l’ASO on-app e l’ASO off-app. La prima consiste nell’ottimizzare tutto il contenuto che lo store ci permette di inserire e che sappiamo ormai dettagliatamente qual è, quindi tutto ciò che è afferente alla parte visibile della scheda della vostra app sullo store.

Per quanto concerne la ASO on-app, è fondamentale tenere sempre a mente che quando un utente sfoglia le app delle varie categorie o quelle che ottiene in seguito a una ricerca sullo store, compie una valutazione molto veloce e approssimativa dell’app. Rimani pochi secondi su quella pagina, guarda il nome e il logo, dai un’occhiata agli screenshot, vedi il rating degli utenti e quanti hanno inviato eventuali recensioni e leggi le prime righe della descrizione. Questo processo e il tempo speso per farlo sono direttamente proporzionali al costo dell’applicazione e inversamente proporzionali al numero di concorrenti che cercano di soddisfare lo stesso vostro bisogno (Figura 9.10). In generale, gli utenti non passano ore a studiarsi e rileggere attentamente tutta la descrizione che avete fatto, osservando gli screenshot in ogni singolo dettaglio, ma sono persone che dedicano qualche manciata di secondi per capire se la vostra app gratuita di meteo è meglio di una delle altre trentacinque appena viste.

Figura 9.10 – La tecnica dell’Elevator Pitch in una vignetta di Forbes.

La vostra scheda dell’app deve quindi convincere l’utente in un tempo brevissimo, ecco perché si parla spesso di utilizzare l’antichissima tecnica di comunicazione cosiddetta Elevator Pitch. Devo convincere uno sconosciuto della bontà della mia idea nel tempo a disposizione di qualche piano di ascensore. Immaginatevi quindi di rimanere con qualcuno che non conoscete e non vi conosce in un ascensore e, nel breve lasso di tempo in cui siete insieme, dovete convincerlo che la vostra idea è quella che si adatta perfettamente a lui/lei.

Per questo motivo le sezioni dei cosiddetti metadata non devono essere assolutamente lasciate in mano ai tecnici, ma, anzi, andrebbero curate da copy professionisti e da grafici più collegati al packaging di prodotto e alla cartellonistica pubblicitaria che all’ambiente digitale in senso stretto.

Descrizione: la descrizione della scheda dello store influenza il posizionamento nel motore di ricerca di Google Play, mentre non ha alcun effetto sul posizionamento nel motore di ricerca di Apple App Store. La descrizione e soprattutto le prime righe sono comunque fondamentali, in quanto spesso decisive per convincere definitivamente l’utente all’acquisto. Una descrizione dovrebbe coinvolgere il lettore attraverso le prime parole e, ove possibile, cercare anche di differenziarsi da tutte le altre descrizioni di app concorrenti. Siate creativi e osate! La cosa interessante è che la descrizione può essere cambiata più volte senza necessità di aggiornare la versione della propria app all’interno degli store. Provate, periodicamente, a cambiarla per vedere se riuscite a trovare un testo più accattivante. La scrittura e la percezione di un testo scritto professionalmente sono estremamente soggettive, perché non esiste una regola matematica, grazie al cielo, ma esiste la matematica delle Analytics che può aiutarci a capire se una descrizione è migliore di un’altra, ovvero se porta più o meno download. Anche in questo caso si potrebbe scrivere un libro sull’argomento, in sole tre parole: originalità, coinvolgimento, sintesi. Nel caso di Google Play, la descrizione dell’app ha anche un piccolo peso in termini di posizionamento nel motore di Mountain View, ricordatevi quindi di verificare l’uso nel testo delle parole chiave più importanti. Non stressate all’eccesso questo aspetto: un testo accattivante e scritto professionalmente dovrebbe contenere in modo del tutto naturale le differenti parole chiave più importanti afferenti la vostra audience e il vostro progetto.

Figura 9.11 – La descrizione non espansa ed espansa di un’app: la prima frase è molto importante e critica.

Screenshot: anche la scelta delle immagini da associare alla vostra applicazione e la loro elaborazione grafica sono molto importanti, tanto quanto le parti testuali, forse ancora di più per le app gratuite e dei videogiochi, ovvero in quei casi dove la scelta dell’utente ricade in pochi secondi. Uno degli errori più comuni nella realizzazione degli screenshot è quello di metterli nell’ordine di funzionamento della nostra applicazione. Come prima immagine, metto la scheda “home” dell’applicazione, poi la sezione uno, quindi la due e via via di seguito seguendo la stessa logica di navigazione di un’app, processo del tutto sbagliato. Dovete catturare subito l’attenzione dell’utente. La prima immagine deve essere la più bella che avete e quella che spiega la funzionalità migliore della vostra applicazione o l’elemento più distintivo del vostro software. Non andate in ordine cronologico, ma in ordine di passione. Le immagini non sono solo immagini, ma possono anche “parlare”. Corredate gli screenshot di testi (mi raccomando, traduceteli nelle varie lingue) in modo da rendere immediata la comprensione dell’app. Addirittura, nell’ultimo periodo una delle cose più creative che ho notato sono alcune app che giocano con gli screenshot e la loro contiguità, creando una grafica unica, senza punti di discontinuità tra le varie immagini (Figura 9.12).

Keywords: il campo dove immettere le parole chiave, presente solo nel mondo Apple, assente in Google Play, è un elemento decisivo per il posizionamento in seguito alle ricerche del motore delle app di casa Cupertino. Avete a disposizione un campo limitato in termini di battute e Apple non fornisce praticamente alcuna indicazione al riguardo. Ho fatto decine di test personalmente con app diverse per capire a fondo il funzionamento dello stesso. Spiegherò nel paragrafo corrispondente alcuni trucchi per compilare correttamente questo campo e ottenere la massima visibilità nelle ricerche degli utenti. Questa stringa testuale va pensata quindi a tavolino e pianificata con la massima attenzione. Chiunque abbia un sito web collegato all’app che ha appena sviluppato può pensare di partire, come ispirazione, dalle chiavi, perlomeno quelle ancora visibili, con le quali già attualmente gli utenti visitano il vostro website. Inoltre, ci sono molti strumenti gratuiti online che lavorano sui sinonimi di parole chiave e parole chiave correlate. Lo stesso Google Adwords vi può indicare spesso volumi di traffico per sciogliere alcuni dubbi che, soprattutto nella lingua italiana, nel caso delle app acquistano ancora più importanza. Cercheranno di più la keyword ricette di cioccolato o ricette di cioccolata, oppure ancora ricette con il cioccolato? L’italiano, così come tutte le altre lingue di radice latina, è molto più complesso e variegato rispetto agli idiomi anglosassoni. Il problema è che il meccanismo delle keywords (e la lunghezza massima) è stato progettato da anglosassoni e i pragmatici discendenti di Shakespeare semplificano molto con “chocolate receipt” e senza tante varianti[58].

Figura 9.12 – Un esempio molto creativo di screenshot, montati e ordinati in modo che possano “comunicare” uno con l’altro.

ASO off-app: la SEO off-page delle app, coinvolgere gli utenti

Per comprendere meglio le ottimizzazioni off-app e la loro importanza dobbiamo capire come funzionano concettualmente i due motori di ricerca di app dei due store principali. Tutto ciò che scrivo è solo un giudizio del tutto personale e frutto delle deduzioni da test che eseguo ormai da anni per comprendere quali siano le variabili che influenzano il posizionamento di un’app all’interno dello store. Non esiste alcun tipo di documentazione ufficiale al riguardo. Anzi, gli esempi riportati da Apple, in particolare sulle linee guida dello store, sono quasi volutamente fuorvianti.

Figura 9.13 – Apple non riporta alcun esempio nella sua documentazione ufficiale online di come compilare il campo keywords: non compilando questo campo, però, sarete alquanto invisibili, se non con il vostro nome dell’app.

La premessa, comune a entrambi gli store, dei rispettivi App Search Engine (ASE) è che questi funzionano molto peggio dei motori di ricerca tradizionali web. Il funzionamento molto banale, e a volte ai limiti della stupidità, degli ASE, secondo me è stato realizzato in questo modo volutamente, dagli stessi che hanno concepito i motori di ricerca. Questo perché, paradossalmente, è molto più semplice realizzare un ASE che non un motore di ricerca tradizionale web per le seguenti ragioni:

Catalogo limitato e incrementale: ogni giorno nascono milioni di pagine web ricchissime di contenuti anche diversi tra loro. Ogni giorno vengono uploadate centinaia di applicazioni, ma il loro numero è infnitamente minore rispetto a quello del web. Il catalogo delle app aumenta in modo incrementale; un motore di ricerca deve continuare a scansionare la rete perché anche ciò che ha già indicizzato può cambiare in ogni istante. Pensiamo alle homepage di un quotidiano online. È certamente più semplice fare una ricerca in un catalogo defnito e limitato rispetto a una in un ambiente completamente indefnito e in continua espansione esponenziale.

Divisione dello store per lingua: quando cercate in uno store, lo fate nel catalogo del Paese che avete selezionato e, normalmente, potete comprare un’app solo nel Paese di residenza in cui siete. In questo senso l’ASE ha un catalogo ancora più limitato e soprattutto sa in che lingua l’utente cerca e propone solo ciò che a catalogo esiste per quella lingua. Per questo il posizionamento della stessa applicazione deve essere monitorato ed è ben diverso da Paese a Paese; ciò avviene anche nel web ormai, ma in modo meno netto: all’interno degli app store la distinzione linguistica è fatta a compartimenti stagni, mentre sul web è molto più fuida. Se, per esempio, cercate la parola chiave “Netfix”[59] sull’ASE con account Paese Italia, non troverete l’app di Netfix perché non è distribuita nel nostro Paese (e in Europa), bensì una serie di app correlate a Netfix e di concorrenti (fnti concorrenti) che cercano di sfruttare il brand americano per veicolare download alle loro app video. Sostanzialmente, non ho alcun risultato, mentre se cerco su un motore di ricerca web la stessa keywords, potrò accedere al sito di Netfix, che poi mi informerà del fatto che non mi posso abbonare in quanto residente in Italia e connesso dall’Italia. Questa divisione linguistica diminuisce ancora di più il numero di schede che il motore deve scansionare per effettuare una ricerca.

Le ricerche web sono molto più varie di quelle app: in linea generale, le modalità di ricerca e la variabilità delle parole chiave che vengono utilizzate sul web sono molto più ampie e complesse di quelle utilizzate nell’ASE. Sul web esistono ricerche lunghissime: “torta al cioccolato senza zucchero e burro + tempo preparazione” diffcilmente verrà usata su un app store sostituita da “ricette cioccolato (o cioccolata?)”. Inoltre la variabilità delle ricerche web è data anche dal continuo aggiornamento e dai trend del momento: diffcilmente sullo store vedrò ricerche del tipo: “nuova fdanzata di Balotelli” o “chi è Dudù”, mentre sul web le ricerche di attualità e di gossip sono un classico.

Nonostante quindi siamo di fronte a un ambiente molto più semplice da indicizzare e da ordinare in termini di risultati, gli ASE funzionano molto peggio dei loro “cugini” web: non riconoscono singolari e plurali, non hanno stop words (se non per l’inglese), ma sono spammati dalle recensioni piuttosto che dal link building. Mi sono più volte domandato perché non ci sia quasi la volontà dei gestori degli store di farli funzionare bene; la stessa Google che è leader incontrastata della ricerca sul web, possiede un ASE che è come confrontare una Matiz con una Ferrari di Formula Uno in termini di accelerazione. Mia opinione personale, soprattutto in casa Apple, è che un funzionamento così banale e stupido sia stato anche fatto per evitare che in alcuni settori si evidenzi asse un dominio sempre dei soliti pochi player così come avviene per il web. Il problema è che funzionando così male l’ASE di Cupertino, molti utenti cercano le app su siti di settore oppure direttamente da Google, che indicizza chiaramente tutte le schede di iTunes a livello testuale. Tenetelo presente quando progettate la strategia SEO del sito web di supporto all’app.

Cerchiamo quindi di spiegare come funzionano i due distinti motori di ricerca Apple e Google Play, sempre secondo mie personalissime deduzioni indirette tratte dall’esperienza e da test che ho svolto in passato e che continuo a fare.

Figura 9.14 – I risultati di una ricerca con iTunes all’interno dell’Apple App Store con keyword “viaggi”.

ASE Apple App Store: il motore di ricerca di Apple è molto semplice da comprendere a una prima analisi. Apple fa un confronto tra i termini di ricerca immessi dall’utente e:

Il nome dell’applicazione.

Il campo keywords.

Il nome del developer.

Tutti questi campi sono limitati in termini di battute e se non avete inserito un determinato vocabolo in uno dei campi qui sopra sarete completamente invisibili al motore stesso. La prima cosa è chiaramente esserci ed essere presenti nel listing. Ma come fa a decidere l’ASE di Apple in caso di più risultati di una ricerca, ovvero quando la keyword immessa dall’utente corrisponde a più di un’app? Chi sta davanti a un’altra e perché? In generale, a parità di keywords, il ranking delle diverse app dipende dal numero di download dell’ultimo periodo, dal numero di download totali, dalla posizione nella propria categoria di appartenenza, dal numero di recensioni della versione attuale, il numero di recensioni totali e dal rating attuale e storico dell’app stessa. La cosa che più influenza le dinamiche di posizionamento di un’app nell’Apple App Store è comunque determinata principalmente dalla concentrazione di download che ha avuto l’app nel periodo stesso. Pensate al tutto come se fosse una tappa durissima del tour de France: ogni volta che un utente scarica la vostra app è come se voi sulla vostra bicicletta riceveste una spinta. Tanti download equivalgono a tante spinte e se i ciclisti (app) davanti a voi vengono spinti (“downloadati”) meno di voi, li raggiungerete e li supererete. Questo sistema permette anche a nuove app di emergere tra i colossi perché viene considerato soprattutto il periodo in corso; la tecnica delle “spinte” consente quindi a giovani corridori, se aiutati dal pubblico, di battere vecchi campioni pluripremiati. Fatevi spingere!

Figura 9.15 – I risultati di una ricerca col browser all’interno di Google Play con keyword “viaggi”.

ASE Google Play: il motore di Mountain View fa figuracce rispetto al suo gemello del web. L’Application Store Engine di casa Android considera come testi i seguenti input:

Il nome dell’applicazione.

La descrizione dell’app.

Il nome del developer.

Come si nota immediatamente, a differenza dell’ASE di Apple, quello di Google Play non presenta il campo keyword, ma prende in considerazione la descrizione dell’app. Questo permette di essere presenti in un numero maggiore di ricerche rispetto all’ambiente iOS. Attualmente questo ASE fornisce una migliore ricerca in termini semantici; per questo motivo, e per la lunghezza del campo descrizione rispetto ai soli cento caratteri delle parole chiave di Apple, la stessa keyword su Google Play genera normalmente un numero maggiore di risultati rispetto a quella di casa Apple. Questo crea una maggiore competizione in ambito di ranking. Purtroppo, il posizionamento delle app e la loro concorrenza per occupare le primissime posizioni sono caratterizzati dal numero di download e dal numero di recensioni, con un peso di queste ultime, però, maggiore rispetto a quelle di Cupertino. Il problema risiede soprattutto nelle app gratuite, dato che il meccanismo di rating e di download via desktop delle app di Google Play è molto più aperto e meno controllato. Nella fase iniziale, quando non c’era nemmeno bisogno di un account Google Plus per poter lasciare una recensione, era addirittura possibile creare dei sistemi robotizzati di download e recensione di app per compiere queste azioni in modo automatizzato. Per questo motivo, soprattutto per le app più anziane, noterete software senza alcun livello di professionalità sottostante e di dubbia fattura con numeri di rating e di recensioni enormi; la stessa cosa invece non avviene così spesso nell’ASE di Apple.

Poiché questi motori funzionano alquanto male, molta della ricerca che avviene sugli store è la cosiddetta ricerca per directory “punta e clicca” (Dmoz è tornato!). Ovvero, si parte dalle categorie e si sfogliano le classifiche: entrare nei top dieci, ma anche solo nei top venticinque di categoria, permette di innescare un circolo virtuoso molto interessante. Occupare le prime posizioni di categoria (o addirittura quelle assolute) concede una visibilità enorme all’app e, di conseguenza, un numero di download molto forti (non dimenticatevi le spinte) che permette di rimanere sempre in alto nella classifica in modo, appunto, virtuoso.

Figura 9.16 – La ricerca “punta e clicca” eseguita su iTunes per trovare una app della categoria “Meteo”.

Contrariamente a ciò, chi non riesce mai a entrare in classifica riceve pochissima visibilità all’interno del negozio e, di conseguenza, pochissimi download cosiddetti organici. Devo perciò definire altri canali di supporto sinergici e complementari all’app store per uscire da un circolo vizioso. Per questo motivo tutta la comunicazione parallela e il marketing dell’app sono necessari se non fondamentali per emergere.

Figura 9.17 – I risultati di una ricerca con Google Play all’interno della categoria “Meteo”.

I voti e le recensioni sono quindi molto importanti non solo per il posizionamento, ma anche perché, come già accennato, “people love winners” e l’utente medio sono molto più disposti a scaricare un’app con cinque stelle e duecento recensioni piuttosto che una concorrente ma senza recensioni.

Figura 9.18 – L’app Sveglia Intelligente ha moltissime recensioni e un giudizio ottimo.
Le app che riescono a presentarsi con questo biglietto da visita ottengono un numero molto elevato di download perché gli altri utenti si fidano del giudizio e delle opinioni dei loro pari.

Come posso ottenere quindi recensioni, una volta terminate quelle di parenti e amici? Tre azioni molto interessanti e importanti sono certamente:

Stimolare le recensioni con notifche push locali: dovete incentivare i vostri utenti a lasciare un giudizio e una recensione sulla vostra app. Chiunque di voi ha già avuto certamente l’esperienza di ricevere dei push locali che vi chiedono, nel caso vi sia piaciuta l’app, di lasciare un giudizio e una recensione sullo store. Questa tecnica è molto valida e aiuta molto a ottenere le valutazioni degli utenti, ma anche qui ci vuole una certa strategia: l’utente, al vostro push, può sostanzialmente rispondere in 3 modi. Ok, e viene ridiretto sulla scheda dell’app nello store dove può lasciare una recensione. No, e l’utente resta nella vostra app e a questo punto il local push viene inibito e non verrà più mostrato. No, e l’utente resta nell’app, ma il local push può essere riproposto. Ricordatevi sempre che gli utenti moderni sono sottoposti a tantissime richieste di coinvolgimento quotidiane; dovete usare il local push in modo intelligente. Se chiedete, come fanno in molti, che cosa penso della vostra app e di lasciare una recensione appena la lancio per la prima volta, non considererò nemmeno la vostra richiesta e, anzi, il pensiero immediato è “ecco mi stanno già stressando”. La vostra app partirà quindi già condizionata da un “fastidio” dal lato utente e in molti diranno di no, magari utenti che poi si innamoreranno del vostro software, ma che, non più stimolati, non vi lasceranno una recensione. Avete perso un’ottima occasione. L’idea migliore è collegare il local push che invita alla recensione ai dati di Analytics della vostra app. Parte il push all’ennesima volta che l’utente apre l’applicazione oppure parte il push dopo x minuti totali di utilizzo o parte il push al completamento del livello y. In questo modo potrete fare le domande giuste agli utenti giusti nel momento giusto: ci saranno molti più utenti propensi a esprimere un giudizio e, lavorando col numero di avvii e l’arco temporale contemporaneamente, andremo a stimolare coloro i quali hanno più apprezzato la nostra app perché l’hanno usata più volte e per alcuni giorni almeno. Non solo i giudizi saranno in generale più positivi, ma anche il loro contenuto avrà una valenza maggiore in quanto espresso da persone che hanno usato approfonditamente la vostra app e la conosceranno molto meglio di un utente che vi lascia una recensione dopo cinque minuti di utilizzo.

Figura 9.19 – Stimolare le recensioni attraverso notifiche local funziona molto bene, ma solo se attuata in modo intelligente, collegandole all’utilizzo dell’app stessa.

Servizio di assistenza clienti effciente: non solo siete obbligati da qualsiasi store a fornire come minimo una mail di assistenza e supporto ai clienti, ma dovete assolutamente controllarla in modo continuativo e intervenire il più presto possibile, soprattutto se è a pagamento, oppure se ci fossero problemi con un acquisto in-app. La maggior parte degli utenti, prima di scrivere una recensione arrabbiata con il voto più basso possibile, cerca sempre di contattare il servizio di assistenza dell’app per ricevere supporto, quindi vi invierà una mail, spesso con toni infuocati. Cercate di rispondere in modo chiaro e nel più breve tempo possibile e, nel caso ci sia stata una transazione monetaria, sottolineate sempre e fn dall’inizio che, nel caso non si risolvesse il problema, verrà rimborsato completamente. Vedrete che basterà una semplice risposta gentile fatta entro poche ore dalla mail del cliente insoddisfatto per smorzare immediatamente i toni e, anzi, vedrete che se riuscirete ad aiutare il vostro cliente e a risolvergli il problema, non solo sarà felice, ma molto probabilmente vi lascerà anche una recensione positiva sullo store. Gli uomini sono animali sociali, come diceva Aristotele, quindi cercate di sfruttare le occasioni di socializzazione con i vostri clienti, anche se cominciano da un problema. Fate vedere che siete vivi, che ci sono persone reali dietro a un’icona di pochi pixel. Non è complesso trasformare le problematiche dei clienti in fantastiche recensioni. Quando gli altri utenti leggeranno che avete dato assistenza e avete risolto il problema di un altro cliente, saranno molto più propensi non solo ad acquistare quell’app particolare, ma, nei casi di maggior successo, ad accordarvi fducia come developer, perché la vostra immagine si trasmette anche a tutte le altre app che avete sviluppato. Le aziende che sanno ascoltare i clienti e le loro esigenze vinceranno la sfda dell’economia del ventunesimo secolo. Siate tra questi!

Figura 9.20 – Una recensione molto negativa, dove si comprende che il cliente ha cercato un supporto dal developer e una volta non ricevuta alcuna risposta e persa la pazienza, ha lasciato queste righe di fuoco. Una recensione come questa, soprattutto se l’app non ne ha moltissime, può seriamente pregiudicare il suo futuro. Fate perlomeno un aggiornamento per metterla più in secondo piano.

Figura 9.21 – Una recensione positiva dopo un’esperienza negativa: trasformare le lamentele in recensioni con un servizio di supporto clienti è strategicamente decisivo, basta essere veloci e onesti, il resto vien da sé.

Utilizzo integrato dei social network: i social network, Facebook e Twitter in prima linea, svolgono un ruolo a volte cruciale per la diffusione della vostra applicazione. Permettete di connettere gli account sociali dell’utente alla vostra applicazione, ma fatelo in modo intelligente offrendo degli incentivi virtuali, ma funzionali anche all’utilizzo dell’app. Ci sono alcuni casi in cui i social sono talmente integrati che non è praticamente possibile utilizzare l’app senza un account sociale.

È il caso studio di Wordz vs Ruzzle: non sempre chi arriva per primo vince, ma spesso conta il numero di “amici” (Figura 9.22).

Wordz è un’app nata nell’agosto del 2011, in Italia trasformata in Parole Puzzle (in questo caso, è stato un errore strategico cambiare il nome nei vari Paesi senza creare un brand forte su Wordz) (Figura 9.23).

Figura 9.22 – Wordz vs Ruzzle.

Figura 9.23 – Wordz (Parole Puzzle) e Ruzzle a confronto: Wordz nasce prima di Ruzzle e la dinamica di gioco è molto simile, quasi identica; cambia solo la strategia a livello multiplayer.

Le dinamiche del gioco sono identiche al famoso Ruzzle ma, contrariamente a quanto molti pensano, è stato proprio Ruzzle a “copiare” in modo più o meno esplicito questa tipologia di gioco introducendo un paio di piccole varianti nelle dinamiche (forse giusto per evitare una causa per plagio). Ruzzle però ha introdotto la novità non nelle dinamiche in sé, ma nel concetto di sfida. Wordz infatti si presenta come un multiplayer massivo a stanze: tutti giocano contemporaneamente la stessa manche e poi c’è una classifica assoluta, una sorta di “tutti contro tutti”, senza che gli utenti abbiano rapporti sociali tra loro.

Ruzzle invece introduce, utilizzando più o meno lo stesso schema di gioco, la sfida uno a uno, partendo dai propri contatti sociali, ma anche a caso in rete. Certo è che il fatto di ricevere una sfida da un amico per partecipare a un gioco, magari un amico col quale abbiamo già giocato insieme o che si definisce il re delle parole crociate ogni volta che spunta una Settimana Enigmistica, ha creato quel social buzz e quel rumore sociale sufficiente a innescare una viralità enorme del gioco, oltre ad avere utilizzato molto bene i propri canali sociali e sfruttato la pubblicazione con app degli stessi. Ruzzle è stato anche integrato in Facebook come applicazione e anche questo fatto ha permesso la diffusione del gioco stesso. Per questi motivi, pur partendo nel mese di marzo del 2012, ben sette mesi dopo Wordz, Ruzzle spopola ed esplode completamente come moda di massa, permettendo ai developer di guadagnare molto in poco tempo.

Figura 9.24 – Andamento dei download di Wordz vs Ruzzle: pur arrivando prima sugli store, con sette mesi di anticipo, l’effetto sociale di Ruzzle ha creato un buzz notevole che ha permesso all’app della Mag Interactive di diventare una vera e propria moda di massa.

È lo stesso Daniel Hasselberg, co-fondatore della Mag Interactive, a sottolineare l’importanza dell’integrazione dei social nel loro gioco e la loro attività sociale stessa: “Il successo negli USA è stato creato completamente dall’attività sui social media” e ancora: “Abbiamo notato una forte attività su Twitter negli USA a inizio dicembre (2012), con #ruzzle, da allora i download sono aumentati tantissimo e continuano ad aumentare fino ad oggi”.

Coinvolgere gli utenti è fondamentale per tutta l’ASO off-app e come strategia generale di marketing.

Pricing delle app e codici di promozione

Le impostazioni di prezzo e i loro cambiamenti sono una fase fondamentale nella sottomissione dell’app all’interno del relativo negozio. Il vostro modello di business è chiaro fin dall’inizio e lo deve essere soprattutto nel caso di app gratuite o a pagamento. Gli app store infatti non permettono di cambiare il modello di business in corso d’opera, mentre è possibile in qualsiasi momento cambiare il prezzo della vostra applicazione, introdurre nuovi pacchetti di acquisto in-app e modificare quelli già esistenti. Il bivio che dovete avere ben chiaro e non modificabile è quindi se vendere, fin dall’inizio o attraverso l’in-app purchase, oppure distribuire gratuitamente il vostro software.

Abbiamo già parlato abbondantemente circa i vantaggi del modello di business freemium che è attualmente quello che rende di più in termini economici, ma anche il modello pay è ancora da valutare.

Vediamo un caso studio personale di cui non posso citare nei dettagli il modello di business: creazione di un’app per professionisti con nicchia di mercato pari a un milione di utenti. Facciamo questa piccola analisi di pricing dell’app.

Scenario 1: app Pay

Prezzo netto di 15,00 $ per acquisto dell’app completa.

Previsione di download anno 1 = 0,1% del mercato.

Download anno 1 = 1.000.000 × 0,01% = 10.000

Fatturato previsto anno 1 = 15 × 10.000= 150.000$

Scenario 2: app Freemium

Prezzo gratuito con 1 in-app purchase da 15,00 $ netti per acquisto app completa.

Previsione di download anno 1 = 5% del mercato.

Download anno 1= 1.000.000 × 5% = 50.000

Previsione di conversione = 30% dei download in-app purchase anno 1 = 50.000 × 30% = 15.000

Fatturato previsto anno 1 = 15 × 15.000 = 225.000$

Permettere il download gratuito e provare la vostra app vi fornirà il vantaggio di acquisire una quota di mercato molto più ampia rispetto alla vendita diretta (e ho tenuto volutamente basse entrambe le percentuali rispettivamente 0,1% e 5%), mentre in caso di modello freemium la percentuale di acquisizione potrebbe essere anche molto più elevata del cinque percento, ma adottiamo un modello neutro-pessimista. Al contempo, prevediamo che il nostro software piaccia: noi crediamo nell’app che stiamo realizzando altrimenti non la faremmo e pensiamo che solo un utente su tre circa che ha scaricato l’applicazione poi si converta all’acquisto del software completo. Anche in questo caso, la percentuale di conversione che ho usato appartiene a un modello neutro-pessimista. Si noti comunque come, a parità di prezzo di vendita del software completo, adottare un modello rispetto a un altro può creare delle importanti differenze di fatturato: nel mondo delle app la revenue non dipende semplicemente dal prezzo, ma anche dalla tipologia di vendita che adottiamo.

Capire che prezzo dare alla vostra applicazione è molto importante e dipende anche dall’analisi della concorrenza che dovreste avere già fatto. Dovete considerare che, a differenza di altri sistemi distributivi, il prezzo delle app presenta due caratteristiche peculiari in ambito digitale:

Il prezzo dell’app è lordo: quando decidete a quanto vendere la vostra app, ricordatevi sempre che dovete sottrarre la percentuale che verrà trattenuta dallo store.

Il prezzo è nella valuta nazionale del consumatore: quando decidete di vendere il vostro software e i relativi add-on, non dovete stabilire un unico prezzo nella vostra valuta, ma una cifra che può variare anche leggermente da Paese a Paese[60]. Potreste adottare delle politiche di pricing differenti per area geografca.

Figura 9.25 – Il sistema di pricing con scelta per Paese di Google Play.

Il prezzo è tendenzialmente bloccato per fasce: la politica di prezzo adottata da Apple è alquanto discutibile per quanto concerne il cambio di valuta, che da sempre l’azienda di Cupertino adotta tra dollari americani ed euro. In linea di massima, un prodotto della mela morsicata che costa mille dollari negli USA, lo potete comprare in Europa a novecento euro. Questa differenza di prezzo si mantiene nelle applicazioni, dove Apple App Store ragiona e funziona per fasce di prezzo (i cosiddetti tier) sempre abbastanza sfavorevoli come tasso di cambio per chi sviluppa in area euro e più vantaggiosi per le aziende americane che vendono ai consumatori europei.

Figura 9.26 – I tier di prezzo standard dell’Apple App Store.

Il mio consiglio, come per gli scenari precedenti, è quello di fare le previsioni in dollari americani e mantenere voi un tasso di cambio medio interno; ancora meglio, utilizzate i nuovi tier di prezzo introdotti da Apple dove la corrispondenza è quasi paritaria di 1 a 1.

Figura 9.27 – I nuovi tier di prezzo dell’Apple App Store.

Potete sempre adottare delle politiche di prezzo di lancio o delle fasi periodiche di sconto per la vostra applicazione: avete un’app che parla di sci? Fate una promozione nel mese di settembre oppure ottobre; avete un’app per le immersioni subacquee? Sfruttare giugno, ma anche il periodo prima delle vacanze di Natale (ai tropici). Non continuate a cambiare il vostro prezzo. I consumatori sono attenti e potreste ricevere delle cattivissime recensioni da chi ha pagato magari 2,99 dollari e il giorno seguente si ritrova la vostra app gratuita. Le promozioni vanno bene in fase di lancio, al momento dell’uscita di un nuovo titolo correlato, oppure in occasioni particolari e per un brevissimo lasso temporale, come il giorno del compleanno dell’app o il giorno seguente il raggiungimento dei 10.000 download e così via. In ogni caso, la promozione deve essere breve, ma dovete utilizzare e sfruttare tutta la comunicazione possibile, magari supportando l’azione con una campagna di advertising scontare o addirittura regalare la vostra app in vendita è un investimento per le famose “spinte” del posizionamento. Se intendete farlo, concentrate tutto il fuoco che avete a disposizione nella stessa direzione. Alternativamente, opzione meno rischiosa per le rivolte dei già clienti in termini di recensioni, potreste pensare di rilasciare la vostra app gratuita in un altro ambiente, in particolar modo per desktop: potreste quindi regalare la vostra fiaba interattiva per coloro che la vogliono vedere e usare sul pc, ma far pagare l’app per i dispositivi mobili. Il contesto è importante: il genitore testa la storia e l’interazione sul proprio pc, magari la fa vedere al bambino/a per guardare il gradimento e, se tutto piace, la compra per iPad, molto più comodo e portabile per il lettino alla sera.

In ogni caso, quando effettuate un cambio di prezzo, osservate attentamente le dinamiche del fatturato nei giorni seguenti che deve chiaramente essere maggiore o uguale del precedente: in caso di fatturato simile, privilegiate l’opzione con più download perché è quella che vi permette meglio di scalare le classifiche di categoria del negozio. Quindi meglio fare 10 download da 1 euro l’uno che 1 download da 10 euro.

Figura 9.28 – Cambio di prezzo di un’applicazione ed effetto sui download: il prezzo aumenta, i download calano, ma il fatturato rimane leggermente superiore.

In qualsiasi modo decidiate di vendere l’app o le sue componenti, gli store vi mettono a disposizione, ogni volta che pubblicate un suo aggiornamento, un numero limitato di codici di promozione. Sono sostanzialmente dei coupon che potete inviare alla mail associata all’account dello store (iTunes e Google Plus) per scaricare gratuitamente la vostra applicazione, pur essendo a pagamento. È forse l’unico momento in cui lo store vi “concede” un regalo: sfruttatelo! Vi consiglio un iniziale utilizzo di circa il 50/70% dei coupon al momento del rilascio dell’app: questi vanno inviati a tutti i soggetti precedentemente individuati per il mailing di lancio, comprese riviste e blog di settore. Tenetevi sempre una quota di codici di promozione, perché vi potrebbe venire in mente o potreste conoscere delle persone o delle aziende sinergiche alla vostra app a cui offrirla con un forte incentivo per coinvolgerli in qualsiasi progetto di comunicazione e marketing. Molto meglio che costringere un terzo a pagare i vostri 2,99 euro per provare la vostra app: è molto meno elegante.

Figura 9.29 – Creazione di un codice di promozione per Apple App Store.

Gestione di campagne pubblicitarie

Personalmente, soprattutto per le app in vendita, vi consiglio di supportare l’app stessa con delle campagne pubblicitarie vere e proprie. Cercate, fin dall’inizio del progetto, di conservare un minimo budget da investire sulle piattaforme pubblicitarie.

Abbiamo già parlato del funzionamento della filiera dell’advertising digitale e di quali siano le possibilità di inserimento, come publisher, di spazi pubblicitari all’interno della vostra applicazione. In questo momento siamo dall’altra parte della barricata, dobbiamo quindi scegliere quali spazi a pagamento scegliere e come selezionarli e gestirli. La prima cosa che devo pensare quando creo un qualsiasi tipo di campagna è comprendere l’audience che intendo raggiungere con i miei messaggi. Per le prime campagne, questa dovrebbe coincidere con quella che avete individuato come utilizzatori iniziali della vostra app. Cercate di dettagliare nel modo migliore possibile la tipologia dei vostri clienti potenziali per:

Dati socio demografci: la vostra app si rivolge principalmente a un pubblico femminile? E a quale classi di età si adatta meglio il vostro software? Volete fare pressione pubblicitaria solo in un Paese in particolare? Dovete prestare molta attenzione a queste caratteristiche di base.

Tipologia di dispositivo: volete fare una campagna solo su smartphone o anche su tablet? Anche questa scelta deve essere chiarissima fn da subito, perché da questa dipendono anche i formati che andrete a utilizzare.

Momento di utilizzo: volete fare pressione in un determinato momento della giornata? Oppure solo per alcuni giorni della settimana? La vostra app di ricette riceve molti download dalle 11.00 alle 13.00? Provate a intensifcare la campagna pubblicitaria in quegli orari.

Tipologia di acquisti storici: una possibilità molto interessante di alcune piattaforme è quella che vi permette di segmentare l’audience anche in base agli acquisti storici di quell’utente (o meglio account) all’interno dello store. Posso quindi decidere di fare vedere un annuncio della mia app videogioco del brivido a tutti gli amanti di cinema horror e agli amanti di heavy metal. Questo tipo di segmentazioni sono molto utili se avete un proflo ben preciso di pubblico per la vostra app e portano a volte risultati estremamente positivi.

Contesto di utilizzo: il contesto di utilizzo della vostra applicazione vi può dare spunti interessanti anche per le altre segmentazioni dell’audience. Un’app dedicata ai ristoranti potrebbe fare maggiore pressione pubblicitaria dal giovedì fno alla domenica mattina; una per il tracking della giornata di sci potrebbe pensare, oltre alla stagionalità, ad applicazioni simili alla propria e così via. Pensate sempre al contesto per segmentare in modo più creativo la vostra audience.

Canale di esposizione pubblicitaria: cercate di capire se utilizzare i vostri messaggi pubblicitari mentre un utente sta navigando sul web, sta sfruttando un social network oppure mentre utilizza un’altra applicazione, magari promuovendo la vostra con un incentivo. È importante comprendere in che modalità volete raggiungere i vostri utenti perché da questo dipende molto la scelta della piattaforma che dovrete utilizzare.

In questo senso possiamo creare una scheda profilo del mio cliente potenziale:

Socio Demo: donna (mamma), dai 25 ai 54 anni, residente in Italia.

Tipologia di Dispositivo: smartphone iOS.

Momento di utilizzo: identico per ogni giorno della settimana e per fascia oraria.

Tipologia di acquisti storici: applicazioni di salute e benessere, cataloghi, giochi, educazione, bambini. Una donna che acquista documentari, flm per famiglia e cartoni animati, ascolta tutti i generi musicali, amante delle serie tv e di libri quasi di ogni genere.

Contesto di Utilizzo: mentre naviga col suo smartphone, mentre interagisce sui social e quando utilizza altre applicazioni.

Canali di distribuzione: piattaforma Google Admob, piattaforma Facebook Ads e piattaforma Apple iAd.

Dopo aver compreso l’audience che intendete raggiungere e il contesto e il momento in cui raggiungerla, dovete pensare alla creatività che volete dare al vostro messaggio pubblicitario: testuale, visuale o video? Standard o personalizzato? A seconda delle scelte che fate, potreste avere delle limitazioni più o meno rigide su diverse piattaforme. Quelle principali vi permettono di gestire più formati. Tutto il team di supporto deve partecipare per selezionare il tipo di messaggio e la creatività. Il contributo dell’area grafica risulta decisivo insieme a quello del marketing. Una buona creatività è determinante per creare l’attenzione dell’utente e favorisce il clic… ops, il tap. Abbiamo già abbondantemente parlato dei formati disponibili e possibili lato publisher. Dal punto di vista dell’inserzionista la situazione è la medesima, vista esattamente dal lato opposto. Infine, dovete scegliere come spendere i vostri soldi. Volete pagare per ogni installazione che viene fatta? Selezionate piattaforme minori che permettono la modalità Pay per Install denominata anche Rewarded. Volete pagare solo chi fa un tap sull’annuncio (l’equivalente di un clic)? Adottate la modalità Pay per Clic/Tap. Oppure intendete pagare per esposizione pubblicitaria? Adottate il modello Display puro Pay per Impression; in ogni caso dovete sempre considerare il cosiddetto costo per acquisizione o costo per download, rispettivamente CPA o CPD per poter equiparare campagne a performance differenti tra loro. È fondamentale, prima di affrontare una qualsiasi campagna pubblicitaria, aver compreso il funzionamento dell’investimento pubblicitario, conoscere sostanzialmente il vostro “pay per che cosa”. Provate diverse modalità e verificate quale sia il modello che performa meglio in relazione alla vostra applicazione e alla vostra audience. Non esiste un modello unico per tutti ma, comparando tra loro le campagne, comprenderete facilmente quale si adatta meglio alla vostra applicazione.

Per fare ciò dovete quindi conoscere le metriche e la terminologia per la lettura dei report delle differenti campagne. Ecco i termini di base fondamentali che si aggiungono alle definizioni già fornite lato publisher.

Cost per Clic/Tap (CPC/CPT): il costo pagato per ogni tap si ottiene da Costo.

CPM: il costo pagato ogni mille esposizioni pubblicitarie del vostro annuncio.

Cost per Acquisition/Download (CPA/CPD): costo per ogni download generato dalla campagna.

Una volta che avete tutte queste informazioni sapete chiaramente il totale dell’investimento e del fatturato e potrete quindi calcolare il costo netto della campagna, dato da:

Costo Netto Campagna = Costo Campagna – Fatturato Campagna

Ricavo/Perdita per app = Prezzo Netto app - CPD

Ecco che cosa dobbiamo calcolare dopo aver investito in campagne distinte:

Campagna 1: pagamento a installazione – Investimento: 1.000 euro.

Campagna 2: pay per tap – Investimento: 500 euro.

Campagna 3: CPM – Investimento: 500 euro.

Prezzo di vendita dell’app al netto delle commissioni dello store: 1,40 $

Costo Netto Campagna 1 = 1000 $ - 466,20 $ = 533,80 $

Ricavo/PerditaCampagna 1 = 1,40 $ - 3,00 = – 1,60 $

Costo Netto Campagna 2 = 500 $ - 560 $ = – 60 $ (ho guadagnato da questa campagna).

Ricavo/PerditaCampagna 2 = 1,40 $ - 1,25 = + 0,15 $

Costo Netto Campagna 3 = 500 $ - 280 $ = 220 $

Ricavo/PerditaCampagna 3 = 1,40 $ - 2,50 = – 1,10 $

Tabella 9.1 – Report scenario 1.

Nello scenario 1 della Tabella 9.1 la campagna che ha performato meglio è certamente quella a clic: per ogni installazione portata dalla campagna abbiamo guadagnato 15 centesimi di dollaro. Ho tralasciato volutamente alcuni dati per le prime due tipologie di campagne in quanto, quando pagate a performance, non tutte le piattaforme che utilizzerete potrebbero fornirvi quei dati. La cosa fondamentale resta comunque quella di comparare il Costo per Download. In futuro investiremo molto di più con campagne pay per tap. Nel caso in cui il ricavato netto della vostra applicazione sia superiore o uguale a 1,25 euro, siete a cavallo! Cominciate a spingere sull’acceleratore e a utilizzare la leva delle campagne per scalare le classifiche e mantenendo un ritorno sull’investimento positivo: allocate il massimo delle risorse finanziarie che potete monitorando costantemente il ROI: potreste avere preso il biglietto della lotteria giusto, cercate di entrare nella classifica dei top e cominciate a esplorare altri mercati geografici. Il bello comincia adesso!

Tabella 9.2 – Report scenario 2.

Nello scenario 2 della Tabella 9.2 vediamo che è la campagna a impression quella che performa meglio: abbiamo indovinato probabilmente il tipo di creatività. Anche qui calcolate il costo netto della campagna e, nel caso sia positivo, rafforzate immediatamente il budget a disposizione.

Concludendo, non esiste un tipo di advertising migliore di un altro. Solo cercando di conoscere e di creare un profilo dettagliato del vostro cliente potenziale potrete trovare le soluzioni ideali alla vostra applicazione. Solo provando e testando le differenti piattaforme potrete comprendere quali siano le modalità più efficaci per pubblicizzare il vostro software. Ricordate sempre la vostra audience anche quando ideate le vostre creatività e stabilite i vostri formati.

Piattaforme per inserzionisti

Vediamo di implementare quindi la campagna con l’audience precedentemente individuata per la nostra applicazione: un’app libro interattivo per bambini dai 6 ai 12 anni pensata da professionisti pedagogici e sviluppata completamente in Italia:

Gambalunga e il Pirata Senzanaso.

Il nostro profilo è il seguente:

Socio Demo: donna (mamma), dai 25 ai 54 anni, residente in Italia.

Tipologia di Dispositivo: tablet iOS.

Momento di utilizzo: identico per ogni giorno della settimana e per fascia oraria.

Tipologia di acquisti storici: applicazioni di salute e benessere, cataloghi, giochi, educazione, bambini. Una donna che acquista documentari, flm per famiglia e cartoni animati, ascolta tutti i generi musicali, amante delle serie tv e di libri quasi di ogni genere.

Contesto di Utilizzo: mentre naviga col suo smartphone, mentre interagisce sui social e quando utilizza altre applicazioni.

Canali di distribuzione: piattaforma Apple iAd, piattaforma Google Admob, piattaforma Facebook.

Cominciamo quindi a effettuare una pianificazione reale partendo dalla piattaforma di casa Apple pensando di pubblicizzare la nostra fiaba interattiva direttamente sui dispositivi per i quali è stata sviluppata mentre utilizzano altre applicazioni che partecipano al circuito iAd.

Figura 9.30 – IAd Workbench, la piattaforma Apple per pubblicizzare le proprie applicazioni.

Campagna su piattaforma iAd

La piattaforma di Apple permette la creazione di una campagna in tre fasi:

Selezione dell’app e impostazione base della campagna.

Targeting della campagna.

Selezione dei banner.

Cominciamo a impostare la campagna su iAd associando l’app che dobbiamo già avere all’interno di quelle da noi gestite nell’account degli sviluppatori e creiamo un nome per la campagna stessa.

Figura 9.31 – Il primo step per la creazione di una campagna su iAd: associamo l’applicazione che vogliamo promuovere e diamo un nome alla campagna.

Il secondo passaggio è uno dei più importanti per sfruttare appieno le opportunità della piattaforma di Apple. La casa di Cupertino è proprietaria dello store dove intendiamo vendere la nostra stessa applicazione e conosce perfettamente gli acquisti dei nostri potenziali clienti e la loro profilazione socio-demografica. I dati di targeting sono quindi molto precisi, sfruttiamoli a dovere e modifichiamo per vedere cosa funziona meglio.

Figura 9.32 – L’inizio della fase di targeting della piattaforma iAd. I dati per segmentare la propria audience sono molto vari e precisi, un’ottima opportunità per gli inserzionisti.

Selezionate in primo luogo le impostazioni manuali in modo da ottenere il pieno controllo del targeting; subito dopo decidete la nazione dove volete lanciare questa campagna, nel nostro esempio abbiamo selezionato l’Italia.

Figura 9.33 – Targeting per dispositivo mobile di casa Apple.

Abbiamo quindi la possibilità di selezionare il dispositivo mobile desiderato per l’audience della campagna: nel nostro caso selezioniamo quindi l’iPad.

Figura 9.34 – Targeting per sesso e classe di età.

Qui le cose iniziano a farsi interessanti e possiamo selezionare in modo molto preciso il profilo del nostro potenziale cliente; stiamo cercando delle mamme con figli dai sei ai dodici anni e decidiamo quindi il profilo precedentemente delineato. È molto interessante poter segmentare per questi dati basilari socio-demografici un elemento presente ormai da tempo in moltissime piattaforme digitali.

Figura 9.35 – Targeting per storico download dell’utente: Applicazioni.

La piattaforma di advertising di Apple offre anche una grandissima precisione sulla tipologia di tutti i prodotti che mette a disposizione attraverso iTunes. Potrete quindi segmentare la vostra audience a seconda dei prodotti che ha già scaricato in passato e potete essere certi che Apple conosce benissimo lo storico degli acquisti dei propri clienti. In primo luogo, cercate di utilizzare solo una cerchia ristretta di app che si adattano al profilo del vostro utente, ma non restringetela a pochissime per evitare di avere un’audience troppo ristretta che verrebbe sottoposta a una frequenza eccessiva dei nostri messaggi pubblicitari. Nel nostro caso studio abbiamo scelto chiaramente le app della nostra categoria e tante altre che crediamo si adattino al profilo selezionato.

Figura 9.36 – Targeting per storico download: Generi Cinematografici.

Il vantaggio di iAd è quello che permette una selezione creativa dell’audience. Concentratevi e pensate attentamente al vostro pubblico: quali sono i film che potrebbe vedere? Quale genere musicale ascolterà? Quali libri legge? E quali sono le trasmissioni televisive che guarda? Potete segmentare l’audience secondo tutte queste caratteristiche e, soprattutto per campagne a livello internazionale in più Paesi, potete restringere molto le varie categorie per ottenere delle nicchie ristrette, ma molto numerose a livello mondiale. Pensate solo a tutti gli amanti dell’horror o dell’heavy metal, ma anche ai fan del jazz e della musica classica o dei film di fantascienza. Cercate di associare questi veri e propri gusti artistici al vostro potenziale cliente: sono certo che vi verranno delle idee molto interessanti. Per campagne ampie e complesse potreste pensare anche di associare delle creatività in linea con la scelta del target… e adesso le idee che avete in testa immagino saranno ancora di più!

Figura 9.37 – Selezione delle categorie di appartenenza delle app dove si vuole promuovere la propria.

Avete anche la possibilità di selezionare le categorie di applicazioni dove volete che compaia la vostra inserzione. Nel nostro caso abbiamo puntato molto sull’audience e sulla tipologia di utente. Ci interessa meno che tipo di applicazione stia utilizzando in quel momento e abbiamo quindi deciso di lasciarle tutte selezionate. Per altre campagne potremmo adottare delle tecniche diverse: nei casi di audience più ampie potremmo puntare solo alla nostra categoria e a un paio similari, dipende tutto da molti fattori e da molte scelte; provate e testate e troverete quelle che fanno al caso vostro.

Figura 9.38 – Scelta se comparire in app per adulti o meno.

Potete scegliere se comparire anche in applicazioni con un rating considerato per soli adulti; nel nostro caso abbiamo deciso di evitare questa scelta; non pensiate che tutte queste app siano cose inguardabili e indicibili. La maggior parte sono videogiochi che contengono magari un po’ di violenza o qualche dialogo eccessivo. Certamente dovete sempre considerare che tipo di app state promuovendo: per un’app del meteo, volendo allargare un po’ l’audience, potremmo anche selezionare questa check box.

Figura 9.39 – Inizio, fine della campagna e selezione dei giorni della settimana nei quali la campagna è attiva.

Dovete impostare la data di inizio e quella di fine della campagna a seconda della durata e del budget a disposizione. Inoltre potete decidere se attivare o meno la campagna in determinati giorni dell’arco della settimana. Nel nostro caso studio abbiamo deciso di mantenere attiva la campagna durante tutta la settimana; per altre tipologie di applicazioni potrebbe essere interessante fare pubblicità solo in alcuni determinati giorni settimanali.

Figura 9.40 – Impostazione del budget e previsionale di reach, impression e tap di iAd.

Questo è un passaggio decisivo per la campagna. Su questa piattaforma l’investimento è pay per clic/tap, anche se Apple suggerisce di inserire un’indicazione di costo per acquisizione per permettere ai propri algoritmi interni di ottimizzare impression e costo per tap. In alternativa, potete decidere se mantenere voi il completo controllo del costo massimo per tap e quindi non suggerire un CPA. Nel nostro caso studio abbiamo impostato un investimento di 500 dollari, suddiviso in dieci giorni e con una spesa media giornaliera di 50 dollari, investendo al massimo dieci centesimi a tap. IAd riporta delle previsioni in termini di impression e tap e download: le previsioni di download della casa di Cupertino non sono molto incoraggianti e mi sembra che il software di previsione non sia ancora tarato alla perfezione, mentre le impression e i tap sono abbastanza corretti (Figura 9.40).

A questo punto dovete passare alla fase della creazione dei banner. La piattaforma di iAd offre un sistema molto semplice per una creatività che vi garantisce l’accettazione della campagna nel circuito e l’alfabetizzazione degli utilizzatori che sono abituati, ma anche assuefatti, a questi messaggi.

Figura 9.41 – Creazione di un banner tra quelli standard di Apple. Le creatività standard di Apple sono animate e colorate e iAd ne offre una quantità abbastanza ampia.

Personalmente vi consiglio, ove possibile, di perseguire anche la strada dei banner personalizzati. A volte, comunque, le animazioni e i colori tipici delle creatività di iAd permettono di ottenere buoni risultati in poco tempo; i costi di realizzazione sono praticamente nulli.

Figura 9.42 – La creazione di banner personalizzati per la vostra applicazione.

A questo punto tutto dovrebbe essere pronto. Vedrete una schermata riepilogativa delle scelte effettuate, dovete solo immettere la carta di credito o scegliere altre precedenti modalità di pagamento preimpostate. Dopodiché la vostra campagna dovrà essere approvata. Non preoccupatevi: i tempi sono molto più brevi rispetto all’approvazione dell’app, soprattutto se selezionate le creatività standard di iAd.

Campagna su piattaforma AdMob

Decidiamo di investire non solo con della pubblicità su altre applicazioni, ma anche con dei banner mentre l’utente sta navigando in Internet con il proprio tablet. Per fare questo ricorriamo alla piattaforma AdMob di Google. Il processo è molto simile a quello precedente, con un numero minore di targeting per utente, ma maggiore per dispositivo e connettività.

Figura 9.43 – Impostazione iniziale della campagna di AdMob.

Nel primo passaggio bisogna assegnare un nome alla campagna, un inizio, una fine e un budget giornaliero con un minimo di 10 dollari al giorno.

Figura 9.44 – Scelta dell’obiettivo di promozione su piattaforma AdMob.

La piattaforma di Google indica se scegliere di promuovere un sito web oppure nello specifico un’applicazione di uno store. Nel nostro caso studio decidiamo chiaramente di fissare come obiettivo la promozione di una nostra applicazione in ambiente iOS.

Figura 9.45 – La segmentazione per modello e per connettività del dispositivo.

AdMob permette una segmentazione molto precisa dell’audience in termini di hardware utilizzato. Avendo impostato una campagna per iPad, la piattaforma ci propone tutti i modelli e le versioni del tablet della Apple. Per la nostra applicazione decidiamo di scegliere i modelli dal 2012 in poi sia wi-fi che 3G+wi-fi. Inoltre, è in questo momento che si può effettuare anche il classico targeting geografico. AdMob offre anche un’altra interessantissima opzione: potete scegliere il contesto di connettività in cui si trova il vostro utente quando far comparire la vostra inserzione. Solo a coloro che sono connessi in wi-fi? Oppure a quelli in mobilità reale e quindi collegati alle reti 3 e 4G? Anche in questo caso alcune applicazioni potranno trovare delle idee e degli spunti interessanti di segmentazione.

Figura 9.46 – Segmentazione dell’audience per caratteristiche socio-demografiche.

Anche la piattaforma di Google permette la segmentazione dell’audience per sesso e classi di età. Effettuiamo per il nostro studio le medesime scelte che abbiamo fatto su iAd.

Figura 9.47 – Scelta della tipologia di creatività: testuale o a banner e associazione dell’applicazione.

A questo punto, potete scegliere se creare un annuncio testuale anche animato oppure un banner più visuale. Personalmente, per pubblicizzare applicazioni vi suggerisco questa seconda scelta. Anche in questo caso dovete associare l’applicazione che intendete promuovere (che è poi anche il link che utilizzerà la piattaforma in caso di tap da parte dell’utente sul banner).

Figura 9.48 – Uploading dei formati dei banner nella piattaforma di AdMob.

L’ultimo passaggio per l’impostazione della campagna su AdMob è quello dei formati dei banner che si intendono utilizzare. Ricordiamo che stiamo facendo una campagna sui browser degli utenti mentre navigano con i loro tablet; per questo motivo i formati, che sono tutti standard iAD come già visto, sono quelli più tradizionali in ambito web: il formato classico quasi quadrato 300×250 pixel, lo striscione standard 468×60 e il classico dei classici: leaderboard 729×90.

Una volta scelte le creatività nei vari formati, siete pronti a partire anche con la vostra campagna sul web per promuovere l’app.

Campagna su piattaforma Facebook

Il ruolo dei social network e la loro diffusione di massa sono un fenomeno ormai inarrestabile e consolidato. Le persone passano sempre più tempo su Facebook, Twitter, Instagram, Pinterest ecc. L’audience quindi è sui social. Per questo motivo c’è l’opportunità di ingaggiarla a un costo molto basso rispetto ai media tradizionali. Nel caso in cui la vostra applicazione non abbia utilizzi professionali, l’ambiente e il “mood” dei social network si adattano molto bene alla promozione diretta delle applicazioni, poiché spesso l’utente si trova in un contesto rilassato di socializzazione, divertimento e passatempo.

Figura 9.49 – La piattaforma di advertising di Facebook.

Inoltre, i social sono utilizzati moltissimo in mobilità e avete quindi l’opportunità di ingaggiare potenziali clienti direttamente sul dispositivo per il quale avete creato la vostra applicazione. Pensate al nostro caso studio: possiamo pubblicizzare il nostro libro interattivo dai sei ai dodici anni direttamente a utenti di Facebook profilati come mamme. Il vostro banner potrebbe comparire nella streamline tra una foto di una pappetta e una nuova bicicletta fiammante. Esperti di marketing attendevano da un secolo questa tipologia di opportunità di advertising che il digitale ha finalmente portato. Non lasciatevi sfuggire queste opportunità: se sapete controllare e sfruttare i nuovi media, saprete gestire la comunicazione e il marketing del futuro. Basta studiare, comprendere, provare partendo da Facebook, che probabilmente è la piattaforma meglio conosciuta.

La prima fase che dovete affrontare sulla piattaforma di Zuckerberg per impostare la vostra campagna è quella di selezionare la tipologia di campagna denominata “Installazioni dell’applicazione”. Immettete quindi la url dello store della vostra app e vedrete comparire automaticamente l’icona come nel nostro caso studio della Figura 9.50.

Figura 9.50 – Il primo step per la creazione di una campagna per applicazioni su Facebook.

Il secondo step vi permette di inserire le creatività della vostra campagna; Facebook vi permette di inserire un formato unico in alta risoluzione e fino a sei varianti di immagine per la stessa campagna. Vi consiglio di utilizzare almeno tre immagini differenti e far girare le vostre campagne sia per comprendere quale tipologia di grafica funziona meglio, sia per evitare di fare un’eccessiva pressione pubblicitaria con banner frequenti e sempre con la stressa creatività.

Figura 9.51 – Inserimento della creatività della nostra app per la campagna su Facebook.

Successivamente la piattaforma pubblicitaria del social network ci propone un’anteprima dinamica della nostra inserzione dove dobbiamo inserire il titolo e un testo “convincente” utilizzando le stesse parole di Facebook.

Figura 9.52 – L’anteprima della vostra inserzione esattamente come comparirà agli utenti iscritti al social network.

Passiamo quindi alla fase successiva delle impostazioni di targeting della campagna che sono il momento in cui Facebook esprime la sua potenza in termini di reach e profilazione della propria base utenti. Alcuni di voi meno legati al marketing potrebbero capire in queste righe le motivazioni di una valorizzazione in Borsa molto elevata di questo social network. I dati a sua disposizione per permettere un targeting mirato delle campagne pubblicitarie sono un valore immenso, e siamo solo all’inizio.

La segmentazione, come si evince dall’immagine della Figura 9.53, parte con degli aspetti collegati all’hardware dell’utente, come il sistema operativo Android o iOS, la tipologia di dispositivo mobile e il contesto di connettività dove si trova l’utente al momento della nostra inserzione pubblicitaria. Successivamente possiamo impostare gli ormai noti dati socio-demografici come la residenza geografica, il sesso e l’età. Su Facebook è possibile selezionare delle età precise e non le classi standard del mondo pubblicitario tradizionale.

Ma il social network non si ferma a queste informazioni. Oltre a ciò, potete segmentare la vostra audience praticamente per tutti i dati presenti nel profilo dell’utente del social, lo stato sentimentale, gli interessi. Le possibilità di profilare gli utenti ideali della vostra campagna sono pressoché infinite e vi permettono di spaziare dai viaggi al cinema, dalla cucina allo sport, dai personaggi famosi agli hobby. Su Facebook esiste un “mi piace” praticamente per qualsiasi cosa: sfruttatelo. Nel nostro caso studio abbiamo deciso di puntare sul successo della serie cinematografica dei “Pirati dei Caraibi” selezionando di fare vedere le nostre inserzioni solo a chi ha fatto “mi piace” su Jack Sparrow e tutta la ciurma nonché sui vari episodi. Cerchiamo le mamme innamorate di un pirata per promuovere la nostra storia interattiva che parla di pirati per il loro bimbo o bimba. Potrebbe funzionare (Figura 9.54).

Il social network di Zuckerberg permette anche dei segmenti di interesse avanzati che offrono delle categorie accattivanti da associare alla vostra comunicazione; troverete anche qui degli spunti molto interessanti e degli ulteriori dati socio-demografici e di consumo molto utili per segmentazioni avanzate.

Figura 9.53 – La sezione del targeting dell’audience su Facebook è tra le migliori al mondo sia in termini qualitativi sia per le possibilità di segmentazione straordinarie di questo social network.

Figura 9.54 – I segmenti di interesse avanzati di Facebook offrono delle categorie che possono calzare a pennello per l’audience che state cercando.

Nel nostro caso studio questi interessi ci hanno permesso di creare un segmento “Genitori con figli dai 6 ai 12 anni” che è utilissimo per la nostra campagna pubblicitaria e perfettamente in linea con la nostra audience. Inoltre, desideriamo che siano possessori di dispositivi mobili iOS: una sorta di “prova del nove” visto che avevamo già in precedenza selezionato di far vedere il nostro annuncio solo agli utenti di Facebook che accedono al social network con dispositivi iOS.

La potenza di Facebook consiste anche nel fatto che, pur selezionando un’audience così segmentata e particolare, la nostra reach potenziale, che vedete in alto a destra della Figura 9.53 sotto il nome di portata potenziale, è pari a 74.000 utenti. Un dato enorme se consideriamo il segmento dei “Pirati dei Caraibi” che è una nicchia molto precisa intersecata con donne dai 25 ai 54 anni, genitori di figli dai 6 ai 12 anni che possiedono un dispositivo iOS e risiedono in Italia.

Dovete sfruttare le possibilità dei social network, sia in termini di comunicazione e gestione degli account social della vostra applicazione sia per attività di social media advertising, viste le possibilità di profilazione e targeting dell’utente che offrono queste piattaforme. Se a ciò aggiungiamo che gli utenti social sono connessi coi loro dispositivi mobili, si può comprendere come questo ambiente sia estremamente adatto alla pubblicità di moltissime tipologie di app.

Trucchi e suggerimenti per emergere

Per poter emergere all’interno degli affollatissimi app store, la vostra strategia di comunicazione e marketing a supporto dell’app deve essere programmata in modo chiaro e preciso. Tutto dev’essere curato nei dettagli e agire sinergicamente cercando di portare l’utente alla conversione, ovvero al download, della nostra applicazione e al suo utilizzo più o meno continuo. La comunicazione e il supporto devono anche cercare di mantenere in vita l’app il più a lungo possibile, amplificando il messaggio degli aggiornamenti, degli ulteriori sviluppi e di nuovi progetti più o meno collegati a quelli già realizzati. Le differenti attività sui canali digitali devono avere quindi come obiettivo comune il download dell’applicazione; tutti i canali devono lavorare contemporaneamente e insieme sfruttando le economie di scala. Produco una serie di immagini di screenshot della mia applicazione che utilizzerò nella foto gallery del sito, posterò sui differenti social network dove sono presente e con le stesse illustrazioni creerò anche le creatività dei miei banner per diverse campagne. Potete perdipiù sfruttare diverse azioni congiunte tra i vari canali utilizzando come fonte di ispirazione la vostra strategia di comunicazione a 360 gradi.

Scoprirete da soli, misurando sempre con attenzione tutto ciò che fate, quali sono le azioni che meglio si adattano alla vostra applicazione. Qui di seguito alcune indicazioni fondamentali per poter concorrere nel mondo del marketing delle applicazioni. Si tratta di una dura battaglia: occorrono tanta competenza e tanta pazienza. Nel caso in cui il committente non coincida con lo sviluppatore, vi consiglio vivamente di ricorrere a dei professionisti anche eventualmente esterni a coloro che sviluppano l’app per poter organizzare il supporto necessario alla stessa. Non smetterò mai di ripetere che fare un’app, metterla sullo store e sperare che magicamente comincino ad arrivare centinaia di migliaia di download, ha le stesse probabilità di successo di un biglietto della lotteria comprato in una qualsiasi stazione di servizio autostradale.

Intercettare lo user agent, sempre: se sviluppate un’app avete già esaminato a fondo il contesto di utilizzo della stessa e sapete quindi quanto sia importante avere ben chiaro come, quando e perché i vostri utenti utilizzano la vostra applicazione. Allargate lo spettro di analisi e cominciate a pensare a due concetti di base: dove potrebbe essere l’utente della mia app e soprattutto che dispositivo deve usare. Pensiamo all’applicazione per il tracking della giornata di sci. Potrei pensare di andare a spingere più a fondo la comunicazione su siti web di appassionati dello slalom, su forum che parlano di fuoripista e così via; ma fermiamoci un attimo e pensiamo anche al dispositivo per il quale abbiamo creato la nostra app: uno smartphone (solo per iOS); fare un banner anche per desktop della nostra applicazione significa certamente sprecare una buona porzione del budget: tutti i non possessori di smartphone iOS. La stessa campagna invece, fatta direttamente su m-site per iOS sui siti web dei bollettini neve, potrebbe funzionare decisamente meglio. Il dispositivo di utilizzo deve coincidere con quello della vostra applicazione. Allargate pure la comunicazione anche ai desktop, ma ricordatevi sempre il device al quale puntate, in particolar modo quando avete il pieno controllo dello user agent: nelle campagne e sul vostro sito web. Per quanto concerne gli investimenti in advertising, abbiamo già visto quanto sia importante, e molto semplice, segmentare l’audience per tipologia di dispositivo. Dovete fare altrettanto, che è un po’ meno semplice e scontato, anche per il vostro sito web. Chiaramente, tutto il sito riporterà link visuali e testuali alla o alle pagine del negozio dove l’app viene distribuita. Quando intercettate il dispositivo ideale per la vostra app, dovete spingervi oltre usando delle tecniche aggiuntive di push. Pensiamo di avere un sito web di supporto a un’app per il mercato dei tablet per differenti sistemi operativi. Visualizzerò il sito senza tecniche di push a tutti gli utenti smartphone e desktop, mentre agli utenti tablet potrei mostrare un banner a comparsa, magari solo dopo qualche secondo di visualizzazione della pagina, che richiami ancora di più l’attenzione e contenga delle chiare call to action visuali e testuali utilizzando per esempio le parole “adesso”, “ora” o tecniche di offerte limitate. Ricordatevi sempre quindi di privilegiare gli user agent ideali per la vostra applicazione e, di volta in volta, di adattare leggermente la comunicazione agli utilizzatori di questi dispositivi.

Cercare effetti esplosivi: il posizionamento nelle parti alte delle classifiche dei negozi di app del vostro software può garantire un enorme successo. Per scalare le graduatorie degli store abbiamo visto che conta molto la concentrazione di un numero di download elevato in un determinato lasso temporale facendo la similitudine con le “tecniche delle spinte” di una gara ciclistica. Cercate in tutti i modi di concentrare l’attenzione simultaneamente sulla vostra applicazione, pianificate campagne contemporaneamente su differenti canali per concentrare i download e le recensioni. Ricordate sempre che le classifiche variano per area geografica: concentratevi dunque nelle zone più deboli o avvantaggiatevi delle aree geografiche che dominate di più, il tutto come fosse quasi una partita di Risiko® digitale. Coinvolgete gli utenti e fateli appassionare, cercate di partire da un numero minimo di recensioni che stimolino i download e soprattutto ulteriori giudizi degli utenti… è sempre dura rompere il ghiaccio ed è sempre triste vedere app senza nemmeno una recensione del fratello dello sviluppatore. Non ci credeva forse proprio nessuno, nemmeno coloro che hanno realizzato il progetto. Dovete concentrare i download e le recensioni in brevi archi temporali, anche perché prima o poi dovrete aggiornare il vostro software e le recensioni ripartiranno quasi da capo. Sfruttate il momento: carpe diem!

Misurare le attività misurabili: avete l’opportunità di lavorare completamente in un ambiente digitale, per cui dovete assolutamente misurare tutte le attività della vostra comunicazione e del marketing per comprendere quali siano le azioni migliori a seconda della vostra audience. Personalmente ho imparato tantissimo dalla misurazione e credo fermamente nella neutralità dei numeri rispetto a giudizi personali. È meglio il banner A o il banner B? All’inizio utilizziamoli entrambi con la stessa identica campagna, poi misuriamo il CTR (o TTR) delle due creatività e avremo la risposta alla nostra domanda. La risposta sarà censuaria perché si basa sul giudizio di migliaia di utenti e non sui gusti personali di pochi componenti di un ufficio marketing. Provate, misurate e imparate: è questo il vero segreto del digitale.

È fondamentale in particolar modo misurare:

Come viene utilizzata la vostra applicazione attraverso l’App Analytics, di cui parleremo nel capitolo successivo.

Il Cost Per Download di ogni singola campagna che facciamo. Per ogni euro investito devo assolutamente sapere quanti download ha generato. Questo attraverso i sistemi di tracking forniti dalle piattaforme per gli inserzionisti stessi.

L’azione di comunicazione fuori dallo store e collegata al vostro sito web di supporto.

L’ASO è fondamentale: prima ancora di pensare al packaging dell’app, in termini di immagini e descrizione accattivanti, dovete pensare a come far trovare il vostro software all’interno dello store. La compilazione del nome e della descrizione di Google Play e del nome e del campo Keyword per iOS è un momento fondamentale della sottomissione, altrimenti potreste essere invisibili. Riprendiamo il caso studio dell’applicazione per il tracking della giornata di sci: cerco di immedesimarmi nella mia audience e penso come un utente potrebbe cercare la mia applicazione in modo più allargato che non con tracking sci, che è molto semplice. Immagino quindi la parola “sci” ancora più generica.

Come si vede dall’immagine della Figura 9.55, l’applicazione “Navionics Ski” è nelle prime posizioni insieme ad app di giochi e con pochissimi concorrenti diretti. Ma l’appassionato di sci potrebbe cercare anche il verbo e non semplicemente il sostantivo. Purtroppo, con questa chiave di ricerca altrettanto generica e forse più correlata al concetto di tracking, in quanto esprime l’azione dello sci e non l’attrezzatura, l’app “Navionics Ski” scompare completamente dalla classifica, come si vede nell’immagine della Figura 9.56.

Figura 9.55 – Ricerca con keyword “sci” all’interno dell’Apple App Store.

Figura 9.56 – Ricerca con keyword “sciare” all’interno dell’Apple App Store.

Figura 9.57 – Ricerca con keyword “piste da sci” all’interno dell’Apple App Store.

Infine, anche nel caso di ricerca ancora più correlata alla tipologia dell’applicazione, cercando “piste da sci” nel motore di Apple, l’applicazione “Navionics Ski” non compare nemmeno, nonostante attualmente ci siano solo tre risultati per quel tipo di ricerca. Non è una questione di posizionamento ma di errata compilazione del campo keyword durante il processo di sottomissione dell’app: sostanzialmente si sono dimenticati di immettere “sciare” e “piste da sci” nel campo keyword. Una dimenticanza del genere però può costare molto caro in termini di mancata visibilità e quindi molti meno utenti potenziali che potrebbero apprezzare la vostra app e scaricarla.

Analizzate periodicamente il posizionamento: la posizione all’interno dell’app store è molto rilevante per innescare il circolo virtuoso necessario al successo esplosivo del vostro software. Sapere e conoscere la posizione all’interno dello store è importante, ma cosa ancora più importante è cercare di comprendere come varia il posizionamento in conseguenza alle nostre azioni di marketing e di supporto all’applicazione: questa è la chiave del successo. Dovete quindi relazionare tutte le attività di comunicazione al numero dei download nello store, all’utilizzo della vostra app da parte degli utenti e ai cambiamenti di posizione all’interno del negozio. Per poter tenere sotto controllo la vostra app, in termini di posizionamento di categoria e generale, esistono servizi di Store Analytics che potete utilizzare. Alcuni sono gratuiti, ma vi chiedono la condivisione dei vostri dati di sviluppatori. Altri sono a pagamento e potete mantenere la segretezza delle vostre informazioni e anche fare dei tracking puntuali su alcune keyword. Vi consiglio di cominciare anche dai primi ed eventualmente passare a un secondo modello per i progetti più importanti o quando state riscontrando un ottimo successo del vostro software. Ne esistono diversi, come ShinyStat: noi ne abbiamo sviluppato uno in versione beta ma, utilizzando ShinyStat nel capitolo successivo, quando si parlerà di App Analytics, ho preferito presentare qui un servizio alternativo così da ribadire la neutralità dell’autore sull’argomento. Usate quello che volete per misurare, basta che lo facciate. Vediamo quindi come esempio di tracking di posizionamento la piattaforma dell’azienda americana AppAnnie[61].

Il software erogato da AppAnnie, in modalità Software As A Service, lavora sostanzialmente con le API degli app store per recuperare i dati e le metriche della Store Analytics e offrire delle dashboard e dei dati più strutturati rispetto a quelli presenti nei negozi di applicazione stessa. La pochezza delle informazioni e la poca usabilità della Store Analytics di casa Apple hanno permesso ad AppAnnie di acquisire forza e rilevanza sul mercato: è molto meglio in termini di utilità, usabilità e “azionabilità” utilizzare questo servizio rispetto ai report presenti nella piattaforma sviluppatori Apple.

Figura 9.58 – La dashboard di AppAnnie che presenta i dati di download della vostra applicazione. AppAnnie recupera i dati direttamente dal negozio di app ogni giorno e li presenta in una forma più usabile di Store Analytics. Questa piattaforma è di gran lunga molto meglio di quella presente nello store di Apple. Google Play invece presenta un’ottima Store Analytics.

Le piattaforme come AppAnnie permettono, inoltre, un’altra tipologia utilissima di servizio: il tracking del posizionamento della vostra applicazione all’interno degli store. Analizzare a che punto della graduatoria di categoria (o categorie come vedremo presto) e soprattutto come cambia il posizionamento in seguito alle nostre azioni di comunicazione è di fondamentale importanza per comprendere l’andamento delle nostre attività ASO e in generale di tutte le attività di marketing a supporto dell’app stessa. Queste tipologie di software continuano a controllare la posizione della vostra app nelle diverse classifiche dello store, registrano il dato e lo tengono in memoria in modo da fornire ai developer sostanzialmente tre tipologie di informazioni di posizionamento:

Ranking Giornaliero.

Ranking Storico.

Premi Applicazione.

Ranking Giornaliero: il software mostra il posizionamento giornaliero all’interno delle classifiche assolute e di categorie della vostra applicazione sia nella classifica di download sia in quella di fatturato che normalmente tutti i negozi possiedono. Con queste informazioni tabellari posso comprendere quali sono le aree geografiche che stanno rispondendo meglio alle mie attività di comunicazione e in quali invece sto perdendo posizionamento. Vediamo il caso studio di un’app e come leggere queste informazioni.

Nelle tabelle della Figura 9.59 viene mostrato il posizionamento nella classifica assoluta dello store e nelle categorie dove l’app è stata inserita nel negozio, nel nostro caso app per bambini (Kids) dai 6 agli 8 anni, categoria libri.

Il 10 di dicembre l’app è entrata nei primi 500 posti della classifica assoluta in ben tre nazioni: Polonia (165esima posizione, new entry da oltre la millesima), Italia (217esimo posto, perde 14 posizioni dal giorno precedente) e Slovenia (258esimo posto perdendo 71 posizioni). L’app è posizionata abbastanza bene nella categoria Kids dove è presente in quinta posizione in Slovenia e in Italia, sesta in Polonia e via via in altre nazioni. L’app performa molto bene nella categoria bambini da 6 a 8 anni e in quella dei libri dove ha raggiunto la prima posizione in Italia e in Polonia ed è nelle top 25 anche in Francia, Spagna, Turchia e Repubblica Ceca. Capire e relazionare alle proprie attività di comunicazione le dinamiche dello store per area geografica è fondamentale[62]. Oltre al dato quotidiano, AppAnnie registra anche i migliori posizionamenti di sempre nelle classifiche della vostra applicazione. Vediamo che la nostra app ha performato benissimo nelle classifiche iPad, come si evince dall’immagine della Figura 9.60.

Figura 9.59 – Ranking giornaliero di un’app nella classifica Apple App Store per iPhone del 10 dicembre 2013.

Figura 9.60 – Ranking massimo giornaliero ottenuto di un’app nella classifica Apple App Store per iPad.

L’app ha raggiunto il secondo posto nella classifica assoluta per iPad in Spagna il 3 marzo del 2013, mentre in Italia è arrivata al settimo posto della classifica assoluta lo stesso giorno e in Uruguay all’ottavo posto. Da notare che ha raggiunto la prima posizione assoluta nella categoria Libri in ben dodici Paesi e in ventidue Paesi nella top ten. Si noti come l’app abbia performato molto bene in Italia e in tutto il mondo latino; buoni riscontri ci sono stati anche da Francia, Germania e Austria, mentre manca quasi completamente il mondo anglofono, che genera moltissimi acquisti sugli store, ma dove l’app non ha avuto lo stesso successo. Si potrebbe cercare di rinforzare ulteriormente la presenza in America Latina oppure cercare di penetrare il mercato anglosassone.

Ranking Storico: questa è la sezione che dovreste controllare quasi quotidianamente, soprattutto nel caso riceviate un numero più alto o più basso di download rispetto alla vostra media giornaliera. Avete a disposizione un grafico, come quello della Figura 9.61 che vi mostra, giorno per giorno, mercato per mercato, come è cambiata la vostra posizione nelle differenti classifiche assoluta e di categoria.

Figura 9.61 – Il grafico dell’andamento del posizionamento di un’app per iPad in Italia dal 1 dicembre 2013 al 9 febbraio 2014.

Potete analizzare giorno per giorno come varia la posizione nelle varie classifiche della vostra app. Queste rappresentazioni grafiche sono utilissime perché vi permettono di capire immediatamente gli andamenti delle vostre attività di comunicazione e di vedere il fenomeno della “tecnica delle spinte”, che abbiamo spiegato in termini di posizionamento all’interno dello store. L’app in questione sottolinea questo fenomeno che, una volta raggiunto un ottimo posizionamento di categoria, riesce a mantenerlo per molto tempo, nonostante esca ed entri di continuo dalla classifica assoluta. Le posizioni dominanti in quelle categorie permettono un numero di download costante e continuo nel tempo e favoriscono l’innescarsi di quel circolo virtuoso fondamentale che è la “tecnica delle spinte”. La strategia è di implementare azioni di supporto da intensificare nei momenti in cui vediamo perdere posizionamenti alla nostra app per sostenerla continuamente e farle mantenere un posizionamento duraturo. Non è semplice, ma è praticamente impossibile impostare strategie del genere se non avete nemmeno accesso a queste informazioni di base da utilizzare come punto di partenza e di arrivo in un processo circolare e continuativo di supporto all’app.

È utilissimo analizzare questo dato anche su base oraria e non semplicemente giornaliera come rappresentato nel grafico della Figura 9.62.

Figura 9.62 – Andamento del posizionamento orario di un’app per iPad nelle rispettive categorie dal 27 gennaio al 9 febbraio 2014.

Da questo grafico si evince molto facilmente il concetto della “tecnica delle spinte”; provate a confrontarlo con quello di installazioni della vostra App Analytics per comprendere quanti download siano stati necessari per il salto di posizione che avviene in determinati orari. Inoltre, questo grafico anticipa il dato di download dello store: il dato è aggiornato quasi in tempo reale, mentre le informazioni sui download hanno un ritardo di 24 o 48 ore. Analizzando i “sobbalzi” del grafico verso l’alto, posso immaginare indirettamente se ci sono stati dei download da quella determinata area geografica. Ciò è utile nella malaugurata ipotesi che non abbiate implementato alcun software di App Analytics all’interno del vostro software prima della sottomissione nello store.

Premi Applicazione: un’ultima tipologia di informazioni fornita dalle piattaforme di Store Analytics è quella dei cosiddetti “Featured”. In pratica, viene registrato ogni qualvolta la vostra app è stata selezionata dall’editor dello store per una posizione particolare. Nel nostro caso studio, l’app in questione ha avuto un ottimo successo: pur non entrando direttamente nella homepage dell’Apple App Store, è stata inserita con un’ottima visibilità in molte categorie e in evidenza in moltissime nazioni. L’elenco dei “premi” è rappresentato nella tabella della Figura 9.63. Potete sapere in che categoria è stata inserita in evidenza la vostra app e in quale Paese. Anche in questo caso, il dato è distinto per tipologia di dispositivo.

Figura 9.63 – I “premi” raggiunti dall’app che viene messa in evidenza dagli editor degli store in alcune categorie particolari. Questi eventi portano moltissima visibilità e moltissimi download all’applicazione.

57. Per chiunque avesse saltato a piè pari quel capitolo: sostanzialmente, ogni volta che un dispositivo qualsiasi accede a un sito web si “presenta” indicando di che tipologia di dispositivo si tratta (e una serie di altre informazioni). Il server deve rispondere in modo diverso a seconda dello User Agent che lo contatta, adattandosi di volta in volta a seconda del device.

58. Avendo lavorato anche nel mondo del cioccolato, vi assicuro che il dilemma cioccolato o cioccolata non è banale.

59. Netfix è la più importante piattaforma di video on demand con canone mensile fsso e possibilità di guardare flm, documentari e serie in modo pressoché illimitato. Per questioni di copyright cinematografci e per le serie tv, Netfix non è attualmente fruibile dall’Unione Europea e da molti altri Paesi, mentre è una realtà consolidata negli USA.

60. Apple è molto più rigida al riguardo e presenta una variabilità ristretta delle scelte, come specifcato nel punto seguente.

61. AppAnnie è un’azienda dedicata alla Store Analytics, quindi all’analisi dei negozi online e dei trend dei mercati delle app. www.appannie.com.

62. Dovreste avere ormai capito quindi le modalità di lettura dei dati proposti relazionando la tabella superiore coi dettagli di quella inferiore.

CAPITOLO 10

APP & STORE ANALYTICS

App & Store Analytics: misurare le performance delle Applicazioni

Uno dei maggiori punti di forza del digitale rispetto all’analogico è la misurabilità del medium; il fatto di poter verificare direttamente e spesso in tempo reale implica risvolti strategici enormi, sia dal un punto di vista del miglioramento e dell’adattamento del proprio servizio in base al comportamento dell’utilizzatore sia da quello della comunicazione aziendale e del marketing. Il digitale è misurabile praticamente al cento per cento e questa è stata una vera e propria rivoluzione nella logica del calcolo del ROI da parte di qualsiasi azienda e investimento nel digitale. È ormai noto che posso misurare esattamente quante volte è stato pubblicato il mio contenuto oppure il mio annuncio pubblicitario, quante volte è stato cliccato e da quanti utenti differenti e soprattutto quanti, di coloro che hanno cliccato, hanno compiuto un’azione rilevante per il mio business (cosiddette conversioni/obiettivi). Un editore online sa esattamente qual è stato l’articolo più visto (la parola letto va oltre la metrica della visualizzazione di pagina) sia in termini numerici, sia in termini temporali del proprio giornale, mentre la stessa cosa è impossibile per la versione analogica del medesimo quotidiano. La misurazione diviene fondamentale anche per la gestione degli investimenti pubblicitari sul digitale: oggi è possibile calcolare il ROI di ogni singola campagna in modo censuario e statisticamente molto valido. Se gestisco un negozio online so esattamente (o quasi) da dove proviene ogni singola vendita, come e quando il mio cliente mi ha conosciuto (una ricerca su Google, una newsletter, un articolo su un blog, un post su un social network ecc.), quante volte è tornato sul mio sito di vendite online e quanto ha acquistato. Ogni singolo euro speso online può essere monitorato attentamente e si può capire esattamente il ritorno che ha portato quel singolo investimento nel corso del tempo. Era il sogno di Lord Leverhulme, fondatore della multinazionale Unilever, che già all’inizio del ‘900 disse: “So di sprecare la metà del mio budget pubblicitario, ma il problema è che non so quale sia questa metà”[63].

Il digitale permette tutto questo ed è stata una delle ragioni, oltre alla qualità migliore, all’interattività e alla personalizzazione dei contenuti, del passaggio al digitale anche di media analogici come la televisione e, recentemente, la radio.

Contemporaneamente, però, il digitale è un ambiente molto recente: Internet, inteso come mass medium, non ha nemmeno vent’anni; YouTube, la nuova tv digitale generalista, nemmeno dieci; gli smartphone e le applicazioni sono mondi ancora più recenti. Tutto è ancora in evoluzione, c’è ancora molto da scoprire e inventare, ambienti in cui non esistono regole e strategie certe, dove innovazione, intuito e competenza sono dei valori fondamentali. E quando non esistono ancora delle regole e delle norme di buona condotta, insegnate in illustri università in tutto il mondo, bisogna sperimentare. La sperimentazione deve essere intesa in termini scientifici. Dobbiamo applicare il metodo scientifico sperimentale di Galileo Galilei alla lettera: “Misura ciò che è misurabile e rendi misurabile ciò che non lo è”, e lo scienziato pisano non poteva sfruttare minimamente Internet[64].

Le scienze che studiano e misurano i fenomeni digitali e i comportamenti degli utilizzatori dei nuovi media si definiscono “Analytics” e vengono di seguito declinate a seconda del medium digitale misurato:

web Analytics: misura le performance di un sito Internet; il sito web è quindi al centro dell’analisi in riferimento ai comportamenti dei navigatori che usufruiscono del suo contenuto.

Mobile Analytics: simile alla precedente, ma focalizzata all’analisi delle visite dei soli utenti che accedono tramite dispositivi mobili, ma sempre utilizzando un browser Internet. Il 100% degli utenti del nostro m-site dovrebbe rientrare in questo segmento di analisi (oltre eventualmente ai tablet del web site). È molto utile e interessante, anche prima di sviluppare un’eventuale applicazione, provare a vedere se ci sono delle differenze di comportamento tra gli utenti del sito normale e della Mobile Analytics.

Video Analytics: permette di comprendere a fondo come viene fruito un contenuto video (e audio) on demand, il sogno di qualsiasi regista cinematografco: quanti spettatori hanno visto il mio flm fno alla fne? Quanti hanno rivisto una determinata scena tornando indietro oppure hanno saltato delle porzioni del video? Quanti l’hanno visto più volte? Tutte queste domande trovano una risposta grazie alla Video Analytics.

Live Analytics: la vera, dal mio punto di vista, Auditel moderna. La Live Analytics permette di conoscere quanti utenti sono collegati in un determinato momento a una trasmissione in streaming live in rete, da un punto di vista censuario e per dispositivo, non attraverso un panel e una ponderazione di pochi utenti misurati rispetto a un universo enorme ed estremamente frammentato: l’utente web e app spazia dai giochi al grande quotidiano online, dal piccolo blog di cucina a Facebook, dalla radio indipendente online al giornale degli scout. La rete è troppo variegata per essere pensata su un numero di persone che, benché ampio e ben proflato, non terrà mai conto della coda lunga editoriale della rete e farà molta fatica a misurare fenomeni che non passano per i brand tradizionali, ma che attraversano la rete potentemente attraendo audience di tutti i tipi. Il metodo censuario, ora che se ne ha la possibilità, rimane una frontiera da percorrere, perché certamente più corrispondente alla vastità di contenuto digitale e di possibilità di scelta dell’utente moderno multimediale, multiscreen, multigiornale.

Social Media Analytics: la misurazione delle proprie azioni sui social network, fondamentale per comprendere se sto comunicando e ingaggiando in modo corretto i miei amici e follower e per capire che cosa vogliono in termini di contenuti e interazioni.

App & Store Analytics: la scienza che studia come vengono utilizzate le applicazioni e le dinamiche delle piattaforme di distribuzione. Tutti i moderni sistemi di Analytics basano il loro funzionamento sulla presentazione di un codice all’interno dell’elemento digitale che si vuole misurare: un tag che viene attivato ogni qualvolta vi sia una trasmissione digitale dal server, dove risiedono le informazioni, al dispositivo utilizzato dall’utente, sia esso un computer desktop, un dispositivo mobile o una connected tv. Questo codice acquisisce l’informazione, la rende anonima disaggregandola (questo dipende molto dai sistemi di Analytics utilizzati) e la inserisce in un database per la sua visualizzazione lato utente. L’analista si collegherà al sito Internet del suo fornitore di Analytics per visualizzare e/o esportare le informazioni acquisite ed eseguire le dovute analisi[65].

Focalizziamo adesso l’attenzione sulla misurazione delle applicazioni. Per misurare le app normalmente utilizziamo due punti di osservazione dell’app distinti:

App Analytics: il punto centrale della nostra analisi è l’utilizzo dell’applicazione attraverso questi strumenti posso comprendere esattamente come gli utenti usano il mio software. Tutte queste informazioni sono fondamentali per intraprendere qualsiasi tipo di azione e di modifca per migliorare la propria app e l’esperienza lato utente. Le informazioni sono disponibili solo esclusivamente utilizzando uno strumento dedicato da implementare all’interno della nostra applicazione; senza l’installazione di un codice di Analytics non avrò praticamente nessuna informazione di utilizzo della stessa.

Store Analytics: in questo caso, invece, il punto centrale di analisi è il canale di distribuzione in relazione alla mia applicazione e alle sue dinamiche all’interno della piattaforma di distribuzione. A differenza della precedente, non è necessario installare nulla all’interno di un’applicazione per ottenere questo set di informazioni.

È chiaramente di fondamentale importanza misurare tutto: ogni vostro progetto di app dovrebbe comprendere non solo la rilevazione di entrambe le tipologie dei dati, ma soprattutto la loro analisi e, ancora più importante, la sperimentazione e le azioni da intraprendere in seguito all’analisi per migliorare sempre di più i propri servizi e i propri investimenti pubblicitari.

Metriche specifiche dell’App Analytics

Lanciare un’applicazione senza avere implementato un sistema di App Analytics al suo interno è come intraprendere un viaggio transoceanico con un’imbarcazione che non è dotata nemmeno di una bussola… e l’oceano delle app è veramente enorme.

Lavorando nel settore delle Analytics da oltre dieci anni, non riesco a capacitarmi di come un gruppo di sviluppatori, dopo aver impiegato tempo ed energie in un progetto ed essere entusiasti del lancio, si accontentino esclusivamente dei dati e delle informazioni della Store Analytics, ignorando completamente le potenzialità dell’App Analytics. Soprattutto non riesco a concepire secondo quali logiche vengano poi adottate delle modifiche e dei miglioramenti all’app basandosi solo su pochissime recensioni e un numero di informazioni molto limitato, mentre potrebbero ragionare con moltissimi dati e metriche. Spero con questo paragrafo di convincere anche i più scettici all’utilizzo di uno strumento di analisi delle performance dell’applicazione.

Ma quali sono e che cosa rappresentano quindi queste metriche e queste informazioni? Passiamo quindi in rassegna con una breve panoramica le metriche principali; chiunque abbia già utilizzato un software di web Analytics troverà tantissime similarità e apprezzerà alcune differenze e sfumature. Esistono differenti software che svolgono questo compito; in questa rassegna gli screenshot sono stati realizzati con l’App Analytics di ShinyStat.

Installazioni: a primo acchito potrebbe sembrare identica alla metrica dei download della Store Analytics, mentre differisce in modo sottile da quest’ultima. Nell’App Analytics le installazioni indicano il numero di volte in cui un’app è stata lanciata per la prima volta in seguito a un download dallo store. Spesso gli utenti entrano nel negozio di applicazioni e ne scaricano contemporaneamente più di una. Non sempre le lanciano immediatamente in seguito al download, alcune app rimanevano per giorni sugli smartphone, abbandonate e mai lanciate… e alcune addirittura cancellate senza mai essere state utilizzate nemmeno una volta. L’App Analytics, lo ricordiamo, analizza i dati di utilizzo dell’app stessa, il numero di installazioni indica quindi il numero di app scaricate ed effettivamente lanciate (la prima volta) dall’utente. Concettualmente, è molto simile alla metrica degli utenti unici assoluti/nuovi visitatori della Web Analytics.

Sessioni: questa metrica indica la sommatoria di tutte le volte in cui l’app è stata lanciata da parte di un device in un determinato arco temporale. Le sessioni sono molto simili al concetto di visite della Web Analytics. In questo caso, a differenza di quanto avviene nella misurazione dei siti web, il software di Analytics riesce a riconoscere (a “sentire”) la chiusura della sessione e non deve quindi basarsi su un arco temporale predefinito di inattività dell’utente, come avviene per il web. Le sessioni sono una metrica base fondamentale per comprendere l’utilizzo della vostra app; il trend delle sessioni vi può far comprendere anche il ciclo di vita di un’app e quanto questa venga realmente utilizzata dagli utenti che l’hanno scaricata.

Figura 10.1 – Le sessioni di un’applicazione misurata con l’App Analytics di ShinyStat.

Durata media delle sessioni: questa metrica indica quanto tempo gli utenti, in media, utilizzano la vostra applicazione. È identica alla durata media della visita presente nella Web Analytics, ma più precisa di quest’ultima. Infatti, nella misurazione dei dati di accesso a un sito Internet, il tempo di permanenza viene calcolato sommando la differenza dei momenti di caricamento tra una pagina e l’altra ma, i software di Analytics perdono il tempo di permanenza sull’ultima navigata da un utente. Questo problema viene ovviato solo in parte ex post, recuperando il tempo dell’ultima pagina dal cookie del browser, nel caso l’utente ritorni sul sito Internet, ma non tutti gli utenti ritornano e molti tempi dell’ultima pagina vengono persi. Vediamo un esempio:

Browser carica PAGINA A alle 20,00 – PAGINA B alle 20,05 – PAGINA C alle 20,15. Il tempo totale di visita viene calcolato come 20,15 – 20,00 = 15 minuti, poiché non si può sapere quanto tempo l’utente sia stato sulla pagina C. Nelle applicazioni ciò non avviene quasi mai, in quanto il software di App Analytics rileva la chiusura dell’app o il fatto che questa venga messa in background; in questo modo è possibile calcolare in modo completo, dall’avvio fino alla chiusura, il tempo di utilizzo di un’app con una precisione massima. Dovete pensare sempre a questa metrica in relazione alla vostra applicazione: il vostro software deve soddisfare un bisogno in pochissimo tempo? Allora desiderate tempi di utilizzo i più bassi possibile, oppure cercate di coinvolgere l’utente e guadagnate in base alle impression pubblicitarie? In questo caso dovrete cercare di allungare al massimo il tempo delle sessioni stesse.

Figura 10.2 – Durata media delle sessioni di un’applicazione misurata con l’App Analytics di ShinyStat.

Distribuzione della durata delle sessioni: questa è un’altra metrica collegata al tempo di utilizzo di un’applicazione da parte dei suoi utenti e mostra la loro distribuzione in determinate lunghezze temporali: quante sessioni fino a 30 secondi, quante lunghe da 30 secondi a 1 minuto, quante da 1 a 3 minuti e così via. È molto importante analizzare queste metriche in relazione alle precedenti per avere un’idea più chiara e completa dei comportamenti degli utilizzatori della mia app in termini temporali.

Figura 10.3 – Distribuzione della durata delle sessioni di un’applicazione misurata con l’App Analytics di ShinyStat.

Utenti unici giornalieri/settimanali/mensili: queste metriche sono identiche a quelle della Web Analytics, ma molto più precise e reali. Gli utenti unici, relativamente a un arco temporale predefinito, indicano quanti dispositivi mobili differenti hanno utilizzato la vostra applicazione nel periodo di tempo predefinito. Un’applicazione con 1.000 utenti unici giornalieri è un’app che è stata utilizzata da 1.000 device distinti in un unico giorno.

Figura 10.4 – Utenti unici assoluti, giornalieri e sessioni a confronto di un’app misurata con l’App Analytics di ShinyStat.

La stessa metrica la ritroviamo per i siti Internet, ma è molto più imprecisa per alcune importanti motivazioni:

Utilizzo misto del device: un browser viene utilizzato normalmente da molte più persone diverse rispetto alle applicazioni presenti in uno smartphone. Il tablet tende di nuovo a essere più simile a un computer desktop, ma molto spesso, anche se utilizzato da soggetti diversi dello stesso nucleo familiare, ognuno ha le sue applicazioni: Giallo Zafferano per la mamma, Football Manager per il papà, Fruit Ninja per il bimbo di 5 anni e Barbie per la fglioletta di 8. Guardando le app presenti in un iPad, si comprende spesso l’eterogeneità e la complessità del nucleo familiare proprietario.

Fruizione del sito Internet da fsso e mobile: l’utente unico di un sito web, soprattutto quando il sito è uno e non si adatta al dispositivo che lo naviga (non presenta un m-site), viene visitato normalmente da molti più dispositivi rispetto a un’applicazione. Pensiamo a un sito Internet di notizie: lo guardo dal computer dell’uffcio, dal browser dello smartphone in pausa pranzo e dal tablet la sera. Per la Web Analytics ci sono stati tre distinti utenti unici giornalieri, mentre in realtà ero sempre io. Per un’applicazione il problema del duplicato è minore. Anche nei casi più a rischio, come un’app identica distribuita per smartphone e tablet su iOS, Android e Windows, questa sarà diffcilmente utilizzata dallo stesso soggetto su dispositivi differenti e quindi risulterà meno duplicata rispetto all’utente web.

Cancellazione dei cookie: la Web Analytics fornisce le metriche degli utenti unici principalmente attraverso l’utilizzo dei cookie. Il software di rilevazione dei dati del traffco web comprende se un browser abbia già visitato (e quando) il sito web in questione, poiché è presente sul browser un determinato cookie. La cancellazione dei cookie e l’utilizzo di strumenti di anonimizzazione della navigazione da parte dei browser rendono imprecisa la rilevazione degli utenti unici da parte della Web Analytics. Se navigo in un sito Internet, poi chiudo il browser, cancello i cookie e navigo nuovamente sullo stesso sito web, sarò stato un utente unico giornaliero per due volte proprio per il fatto che ho cancellato i miei cookie tra una visita e l’altra (sarò anche un nuovo visitatore). L’App Analytics non funziona tramite cookie, ma attraverso l’attribuzione di un numero di identifcazione univoca del dispositivo collegato al download dell’applicazione. Quando lancio l’app per la prima volta, il software di App Analytics attribuirà un id identifcativo a device+download. Ogni volta che rilancio l’app, è come se il software di Analytics vedesse passare un numero di targa da lui stesso assegnato. I numeri di targa diversi in un determinato arco temporale costituiscono il numero di utenti unici di quel periodo di tempo.

In ogni caso, l’analisi degli utenti unici per distinti archi temporali è una metrica fondamentale per comprendere la durata della vostra applicazione all’interno dei dispositivi degli utenti che l’hanno scaricata. Gli utenti unici rappresentano la vostra audience reale e sono il dato che più vi fa percepire la frequenza d’uso della vostra app a prescindere dal suo successo in passato. Anche software che hanno avuto enormi esplosioni, come Ruzzle, prima o poi avranno una caduta degli utenti unici giornalieri, nonostante milioni di download.

Schede Viste: la metrica delle schede viste per le applicazioni è identica a quella delle pagine viste della Web Analytics. Una scheda è una “pagina” di un’app. Questa metrica fornisce il numero delle schede visualizzate in un determinato arco temporale, indicando la profondità di utilizzo di un’app. Questa metrica è da analizzare con molta attenzione e sempre in relazione al design e all’usabilità della vostra applicazione. Analogamente a quanto accade per un sito web, questo dato può cambiare moltissimo a seconda del layout dell’app e in seguito a modifiche allo schema di navigazione della stessa. Comprendere quanto in profondità utilizzano la vostra applicazione è molto importante.

Tempo Medio Scheda: questa metrica indica la media di visualizzazione di una singola scheda da parte degli utenti di un’applicazione. La metrica va giudicata in base all’utilizzo della vostra app e a seconda di ogni caso specifico. Un tempo breve o lungo per scheda può avere risvolti diametralmente opposti, a seconda della tipologia di software che stiamo distribuendo.

Figura 10.5 – Andamento del tempo medio di visualizzazione di una scheda di un’applicazione.

Dettaglio Schede: questo report indica quali sono le schede più visualizzate nel corso del tempo all’interno di un’applicazione. In questo modo è possibile scoprire quali siano le sezioni più utilizzate dagli utenti. Un’app di informazioni, così come un sito web, conosce sempre qual è stata la notizia più vista all’interno dell’applicazione. I software di Analytics permettono normalmente di attribuire dei parametri e di raggruppare le pagine tra loro per fornire delle analisi aggregate del proprio contenuto digitale. Comprendere quali siano le sezioni della vostra app che vengono utilizzate di più dai vostri utenti vi permette di ragionare su eventuali strategie di sviluppo ulteriore dell’app con cognizione di causa. Analizzate e guardate sempre questi dati per capire se e come sia possibile migliorare l’accessibilità alle zone più viste oppure, per contro, mettere in maggiore evidenza le sezioni che vengono utilizzate di meno dai vostri utenti. Analizzare con cura la fruizione del proprio contenuto permette di comprendere meglio anche quale bisogno del consumatore state soddisfacendo e come lo state facendo.

Figura 10.6 – L’andamento grafico e il dettaglio tabellare delle schede viste di un’applicazione.

Eventi: gli eventi sono fondamentali nella misurazione delle applicazioni. Si definisce evento una qualsiasi azione che non può essere misurata “internamente” all’app oppure che si basa su una determinata gesture dell’utente nel caso di app interattive. Le applicazioni permettono interazioni con il mondo offline e con altri canali: in moltissime app per smartphone aziendali è possibile inserire un pulsante o un numero di telefono che faccia partire una telefonata: questo pulsante deve essere “instrumentato” a dovere con il software di App Analytics in modo che possa contare quante volte è stato premuto il tasto della chiamata; non tutte le telefonate probabilmente andranno a buon fine, ma molte sì e possono essere perfettamente misurate. La stessa tecnica deve essere utilizzata quando permettiamo che la nostra app interagisca con altre presenti sul dispositivo: lascio condividere sui social network oppure via mail il contenuto dell’app oppure lo salvo sul dispositivo (un’immagine, un video, un record ecc.)? Quanti dei miei utenti hanno fatto questa azione? Quanti mi fanno pubblicità in modo naturale su Facebook condividendo in un qualche modo il mio marchio? Poiché avete investito tempo e denaro per creare queste funzionalità, è di fondamentale importanza misurare come esse vengano utilizzate e quanto siano apprezzate dagli utenti. Per coloro che sviluppano interazioni avanzate con l’utente, l’utilizzo degli eventi e la loro implementazione diventano fondamentali: riuscirete a capire che cosa fanno realmente i vostri utenti e quali interazioni apprezzano di più. Gli eventi collegano quindi l’analisi interna dell’applicazione con il mondo esterno e con altre applicazioni. Questi spesso sono i motivi per i quali avete creato un’applicazione free: la loro misurazione equivale a quella del raggiungimento di determinati obiettivi della vostra comunicazione strategica. Se avete creato un catalogo interattivo gratuito accattivante per i vostri utenti, volete comprendere quanti condividono su Facebook i vostri prodotti, perché era uno degli obiettivi dell’app. L’analisi degli eventi è forse la parte cruciale dello studio dei comportamenti dei vostri utenti mentre usano la vostra applicazione. Dovete taggare qualsiasi cosa: in questo modo avrete la risposta a decine di domande che vi siete fatti in fase di sviluppo. L’analisi è utilissima a tutto il gruppo di lavoro per capire se alcune strategie marketing implementate hanno successo, per comprendere se le interfacce che ho costruito vengono utilizzate correttamente dai nostri utenti, per imparare dove la nostra app ha più successo e individuare eventuali colli di bottiglia o moduli che abbiamo sviluppato con tanta fatica e che, magari, non hanno nessun successo lato utente. Capire e analizzare gli eventi per moduli di sviluppo da parte delle aziende che realizzano applicazioni è uno degli elementi vincenti aziendali nel medio e lungo periodo. Mano a mano che creo i moduli e li implemento in differenti applicazioni, posso comprendere, in base ai dati di utilizzo, quali abbiano maggior successo e in quali casi di applicazione. Gli sviluppatori potranno pensare quindi di implementare i moduli di maggiore successo anche in altre app, magari riadattandoli al contesto di utilizzo così come di abbandonare invece i moduli meno utilizzati, perlomeno nei medesimi contesti d’uso.

Richieste per Evento: gli eventi, come le schede, possono avere dei sottolivelli di dettaglio che permettono di ottenere un’immagine completa dell’evento stesso: non vedo solo che hanno condiviso su Facebook un’immagine della mia applicazione, ma so anche esattamente quale sia stata l’immagine stessa dell’app nel dettaglio (Figura 10.7).

Versioni: questa metrica suddivide le sessioni dell’app a seconda della versione lanciata dall’utente. Un’applicazione dovrebbe essere aggiornata per migliorare le sue funzionalità ed espanderle, così come per rimediare a eventuali lacune segnalate dagli utenti. A differenza della Web Analytics, però, l’aggiornamento di un’app è valido solo per coloro che scaricano l’applicazione dopo che è stata aggiornata dallo sviluppatore. Tutti i dispositivi che avevano già scaricato l’app la devono aggiornare, altrimenti continueranno a utilizzare la versione precedente dell’app. Questa differenza con il web è fondamentale: una volta aggiornata una pagina, questa viene visualizzata in modo nuovo e aggiornato da tutti per le app (non gli m-site o il contenuto dinamico). E moltissimi utenti non aggiornano, perlomeno immediatamente, tutte le app che utilizzano.

Figura 10.7 – Andamento grafico degli eventi e dettaglio tabellare delle richieste per evento di un’applicazione.

Attraverso questo report è possibile comprendere quanti dei nostri utenti stiano ancora utilizzando una versione non aggiornata ed esattamente quale versione.

Device: questa metrica è peculiare dell’App Analytics e indica la distribuzione delle sessioni per tipologia di dispositivo utilizzato. È possibile vedere, normalmente, il nome del modello e la versione del software utilizzato. Questi dati permettono agli sviluppatori di testare le proprie app partendo dai modelli più utilizzati dalla propria utenza. Il numero dei device presenti sul mercato e la loro frammentazione, non solo per tipologia e versione di sistema operativo ma anche per risoluzione e dimensione dello schermo, rendono la vita degli sviluppatori e la fase di test delle app sempre più complesse e faticose. Comprendere, in base al reale utilizzo dei propri utenti, dove focalizzare gli sforzi nell’analisi e nell’usabilità del proprio software diventa essenziale.

Figura 10.8 – Distribuzione delle sessioni in base all’utilizzo dei dispositivi di un’applicazione.

Sistemi Operativi: questa metrica rappresenta la distribuzione delle sessioni di utilizzo di un’app per il sistema operativo. È la metrica base anche per la segmentazione delle altre per comprendere le differenze di performance della stessa applicazione distribuita su differenti sistemi operativi. Nel caso in cui la vostra app sia presente per un solo sistema operativo, questa metrica è del tutto inutile.

Connettività/Operatori: questa metrica è specifica dell’App Analytics e per alcune tipologie di applicazioni e può risultare determinante la sua analisi. I dati di questo report indicano in che modalità era connesso l’utente durante l’utilizzo della vostra applicazione, ovvero quale banda presunta ha la nostra audience durante l’interazione con il nostro software: LTE, 3G, wi-fi ecc. L’analisi di questi dati è relativa agli obiettivi della vostra app: in base alle informazioni dei report potete decidere se alleggerire sempre di più la vostra app nel caso di connessioni in 3/4G e soprattutto in 2G, mentre potreste pensare di erogare anche contenuti più pesanti (immagini, video) nel caso in cui abbiate un forte utilizzo da reti wi-fi.

Figura 10.9 – Distribuzione delle sessioni in base alla connettività dei dispositivi di un’applicazione.

Geolocalizzazione: questa metrica, identica a quella della Web Analytics, risulta molto precisa a livello nazionale, ma molto meno a livello regionale, poiché gli IP assegnati in mobilità spesso non hanno una collocazione geografica a livello di mappatura. Diverso è il caso di un’applicazione che richieda l’attivazione del segnale GPS del dispositivo: è possibile rilevare anche a livello di Analytics lo stesso dato e creare una mappa anonima e aggregata di punti di utilizzo precisissimi sulla mappa. Vista la dimensione dei canali di distribuzione, le app presentano una quota di espansione geografica a livello mondiale forse addirittura superiore a quello dei siti web. È molto facile che un’app venga scaricata dal Giappone al Marocco e dagli Stati Uniti a Singapore ed è molto utile comprendere in quali Paesi e in quali aree geografiche stia riscuotendo maggiore successo.

Chiusure Anomale (Crashes): se “instrumentata” correttamente, la vostra applicazione può segnalare al software di App Analytics la sua chiusura anomala. Questa metrica indica appunto quante volte è avvenuto il crash dell’app… ed è forse l’unica metrica che vorreste avere sempre a zero nel corso del tempo.

Figura 10.10 – Comparazione del numero di sessioni col numero di crash di un’applicazione. Non guardare nemmeno i dati dell’App Analytics può portare a situazioni come queste, dove un’app utilizzatissima continua a non funzionare in tre quarti delle sessioni. Un problema grave e non rilevato per molto tempo da parte dello sviluppatore.

Metriche specifiche della Store Analytics

L’analisi e le metriche dei negozi di distribuzione delle applicazioni vengono in primo luogo fornite dagli store stessi all’interno dei pannelli per i developer. Inoltre gli store forniscono i dati esternamente, attraverso delle API che possono venire integrate dai software di App Analytics, come ShinyStat e AppAnnie, in modo da ottenere tutti i dati in un’unica dashboard e poterli confrontare tra loro immediatamente. Partiamo quindi vedendo quali metriche forniscono i due principali app store: Apple App Store e Google Play.

Apple App Store forniva pochissime informazioni ai developer e presentava una gestione dei dati a livello temporale alquanto discutibile, finalmente corretta nell’estate del 2013. Apple è allora passata da una mera rendicontazione contabile e amministrativa a una piattaforma vera e propria di Store Analytics. Ecco le novità:

iOS Sales: i dati erano tutti aggregati e uno sviluppatore con molte applicazioni poteva fare un po’ di fatica ad analizzare i dati, poiché non venivano rappresentati i download per singola applicazione nel corso del tempo ma solo come dati aggregati di tutte le app sviluppate. Dopo il recente aggiornamento, i dati sono ora disponibili con un’ottima veste grafica, un calendario più gestibile e soprattutto i dati globali per lo sviluppatore e quelli per la singola applicazione sono segmentabili per le diverse variabili e con la possibilità di salvare delle dashboard personalizzabili. Possiamo quindi analizzare i dati:

Analisi globale developer: in questo caso l’analisi verte su tutte le app possedute e distribuite sotto il cappello di un singolo sviluppatore. Sono dati estremamente utili ed effcaci per comprendere quali siano le aree geografche dove riscuotono maggior interesse le nostre applicazioni, così come le categorie dove abbiamo ottenuto i migliori risultati.

Analisi per singola applicazione: questi dati sono il punto di partenza fondamentale per analizzare le performance di una singola applicazione.

Un altro punto di vista di analisi è collegato al modello di business:

Analisi per download: tutti i dati analizzati vengono indicati per numero di download eseguiti dagli utenti a prescindere da quanto incassato, mescolando applicazioni gratuite e a pagamento.

Analisi per fatturato generato: tutti i dati presi in esame utilizzando questo punto di osservazione sono relativi al fatturato generato dalle (o dalla) proprie applicazioni; in questo caso i dati di vendita diretta sono mescolati a quelli relativi a eventuali in-app purchase.

A prescindere dal punto di vista che adotterete, è fondamentale segmentare queste informazioni per alcune variabili che Apple, finalmente, mette a disposizione. Questi dati sono l’origine delle vostre idee e strategie di marketing e di comunicazione.

Figura 10.11 – Il grafico dell’andamento dei download di un’app all’interno di Apple App Store.

Figura 10.12 – Lo stesso grafico precedente, ma dal punto di vista dei guadagni per lo sviluppatore.

Segmentazione per area geografca: in questo modo potete visualizzare il numero di download per provenienza territoriale: la vostra app va forte in Asia? Oppure ottiene il massimo successo in Europa? Apple fornisce un primo livello di segmentazione per continente (ricalcando la divisione che utilizza anche in iTunes), ma è possibile, e dovete farlo, analizzare anche questi dati a livello nazionale. È importante collegare queste informazioni con eventuali campagne o azioni sui social network che state svolgendo: pianifcate le azioni, fatele, analizzate i dati e soprattutto il loro scostamento dallo storico e dalla media. Avete cominciato a twittare dal vostro account anche in francese? Provate a vedere in questi grafci che cosa succede.

Figura 10.13 – Andamento dei download di un’applicazione per area geografica continentale.

Figura 10.14 – Andamento dei download di un’applicazione per area geografica nazionale.

Segmentazione per tipologia di dispositivo (per piattaforma): in questo caso i dati vengono suddivisi per il tipo di dispositivo sul quale è stata installata l’applicazione che distribuite. Descrivere quanto siano importanti anche queste informazioni è ovvio. Pensate al vostro prossimo banner: punterete sugli iPhone o sugli iPad? L’importante è avere l’informazione iniziale e la strategia che vorrete adottare: potreste decidere di cavalcare l’onda dei dispositivi che già attualmente installano il vostro software oppure fare pressione pubblicitaria verso le tipologie di dispositivi con l’andamento peggiore per cercare di sostenerle e invertire la tendenza. Comunque decidiate di agire, dovete farlo come sempre con consapevolezza e analizzando ciò che succede ai dati in seguito alle vostre azioni. Imparerete moltissimo: è questa l’essenza della magia delle Analytics.

Figura 10.15 – Andamento dei download segmentati per tipologia di dispositivo.

Segmentazione per categoria: in questo caso i dati vengono segmentati a seconda della categoria di pubblicazione dell’app. Chiaramente è un segmento utile solo da un punto di vista di analisi multiapplicazione, ovvero con gli occhi di chi possiede più di un software sullo store dell’azienda di Cupertino. Questi dati sono molto utili per i developer, non solo quelli quantitativi ma anche quelli relativi al fatturato, per capire il ritorno sull’investimento per categoria di app. Non inserisco il grafco di questa sezione perché, attualmente, un bug ancora presente in piattaforma riporta solo il grafco degli andamenti e non lo segmenta. Visivamente il grafco è quindi identico a quello delle Figure 10.11 e 10.12, mentre fortunatamente i dati tabellari sono corretti.

Segmentazione per negozio (Content Type): nel caso in cui la vostra o le vostre app vengano distribuite sia sul negozio per dispositivi mobili sia su quello dello store per desktop (cosiddetto Mac OsX) troverete la segmentazione da questo punto di vista in questi report.

Figura 10.16 – Andamento dei download segmentati per negozio app store classico o Mac OsX Store.

Segmentazione per modello di business: in questo caso vengono rappresentati i dati suddivisi per tipologia di download, se gratuito o a pagamento. Questo è un dato che, in teoria, dovreste sempre avere nella vostra testa: è il vostro incasso giornaliero.

Figura 10.17 – Andamento dei download segmentati per Free o Pay.

Risulta estremamente utile, se non addirittura essenziale, utilizzare i segmenti intersecandoli tra di loro per ottenere una visione di queste informazioni ancora più interessante e strategica. In alcuni casi, gestire e fare un corretto uso dei segmenti multipli è la vera differenza tra un analista e un mero visualizzatore di report.

Figura 10.18 – Andamento dei download con segmenti multipli: le mie app della categoria Libri, in Europa. Distribuzione dei download a pagamento e gratuiti.

Oltre a queste informazioni la consolle dell’Apple Store per gli sviluppatori fornisce un pannello di visualizzazione delle recensioni della propria app. Praticamente le stesse informazioni pubbliche sullo store, ma in un formato più testuale; è purtroppo impossibile per il developer interagire con gli utenti che hanno recensito e votato la vostra applicazione.

Google Play Store Analytics: Google investe da anni ormai nella misurazione del digitale: ha comprato il software Urchin e lo ha trasformato in Google Analytics, distribuendolo gratuitamente in tutto il mondo in cambio della condivisione del dato. Google sa quanto sia importante e quale sia il valore economico della misurazione e dell’informazione. Infatti, la piattaforma Google Play fornisce molte più informazioni spesso complementari all’App Analytics ed estremamente utili per comprendere l’andamento delle vostre applicazioni all’interno del negozio di Mountain View.

Fin dall’interfaccia iniziale della consolle per gli sviluppatori di Google si ottengono le informazioni storiche base suddivise per singola applicazione.

Installazioni Correnti / Installazioni Totali: queste due metriche sono fondamentali poiché indicano il numero di download attivi (un’informazione completamente mancante da parte dell’Apple Store) in relazione a quello totale dei download che la piattaforma fornisce. Il rapporto di questa metrica è importante per il successo a medio-lungo termine del vostro software e va analizzato costantemente soprattutto nel primo periodo dell’app e in seguito a eventi particolari.

Figura 10.19 – Grafico a sei mesi delle installazioni attuali di un’applicazione in Google Play.

Voto Medio / Numero di Voti: questa metrica indica immediatamente il voto medio totale raggiunto dalla vostra applicazione e il numero di voti che ha generato questa media.

Arresti Anomali: identica alla metrica dell’App Analytics, ma fornita direttamente da Google Play.

La piattaforma messa a disposizione, a differenza di quella di Apple, scende nel dettaglio di ogni singola applicazione, fornendo le seguenti statistiche di analisi e rappresentandole graficamente una a una con la possibilità di compararle tra loro.

Installazioni attuali per dispositivo: questa metrica, misurata in modo molto preciso da Google, rappresenta il numero di device sui quali è presente la nostra applicazione giorno per giorno.

Installazioni giornaliere per dispositivo: è il dato fornito dallo store molto simile a quello dell’App Analytics; indica il numero di download giornalieri della nostra applicazione.

Figura 10.20 – Grafico a un mese delle installazioni giornaliere di un’applicazione in Google Play.

Disinstallazioni giornaliere per dispositivo: altro dato che solo Google Play fornisce; indica quanti dispositivi hanno eliminato l’applicazione. Anche questa è una delle poche metriche che sogniamo sempre a zero.

Figura 10.21 – Grafico a un mese delle disinstallazioni giornaliere della stessa applicazione in Google Play.

Upgrade Giornalieri per dispositivo: questa informazione, molto simile alla metrica delle versioni presenti nell’App Analytics, indica il numero di download dell’aggiornamento di una determinata app. È da notare che, normalmente, l’upgrade delle applicazioni su dispositivi Android è molto più immediato rispetto a quello Apple in quanto spesso gli aggiornamenti sono automatici.

Le metriche precedenti vengono inoltre fornite oltre che per i dispositivi anche per gli utenti dove l’utente è l’account di Google Play utilizzato per il download dell’app. Più utenti possono gestire lo stesso device Android con un account distinto oppure installare la stessa app con lo stesso account su dispositivi differenti. Normalmente i dati e i trend sono molto simili a quelli dei dispositivi anche se è utile analizzare e rilevare eventuali scostamenti. Da segnalare, però, tra queste metriche le Installazioni totali per Utente che permettono di vedere l’andamento dei download cumulato fornito dallo store nel corso del tempo.

Valutazione media giornaliera: questo grafico indica i giorni in cui la vostra applicazione ha ricevuto almeno una recensione e il punteggio ottenuto o la media nel caso di più recensioni nello stesso giorno.

Figura 10.22 – Grafico dell’andamento della valutazione media giornaliera di un’applicazione in Google Play.

Valutazione media cumulativa: questo grafico rappresenta l’andamento del punteggio medio ottenuto dalla vostra applicazione nel corso del tempo.

Figura 10.23 – Grafico dell’andamento della valutazione cumulativa di un’applicazione in Google Play segmentata per versione di dispositivo.

Ma i dati di app store che fornisce Google Play non finiscono qui: la piattaforma permette di segmentare tutte le metriche appena descritte. Inoltre Google Play fornisce due benchmark o tabelle di confronto di ogni metrica segmentata, facendo vedere qual è la media di categoria a cui appartiene la vostra applicazione e confrontandola anche con quella delle prime 10 app appartenenti alla categoria stessa. Il tutto per i seguenti segmenti:

Segmento Versione di Android: le metriche possono essere segmentate per vedere su quale versione di Android sta ottenendo maggior successo o insuccesso il vostro software. Un’app che viene installata molto (e disinstallata poco) su versioni molto recenti del sistema operativo ha un maggiore potenziale di successo rispetto a quelle distribuite su versioni più vecchie di Android. Vista la frammentazione di questo sistema operativo, l’analisi di tali dati risulta molto importante.

Segmento Dispositivo: questo segmento indica la distribuzione sui diversi modelli di dispositivi mobili dove ovviamente è presente il sistema operativo di Google.

Segmento Paese: è estremamente utile segmentare le metriche dello store con questi dati per comprendere appieno le dinamiche di distribuzione e di marketing virale che sta ottenendo la vostra applicazione nelle diverse aree geografche del mondo. È molto utile, anche in ottica di espansioni e localizzazioni linguistiche, confrontare i propri dati con quelli dei benchmark forniti dal sistema: saprete esattamente quale sarà il vostro prossimo mercato geografco da conquistare. Analizzare con cura queste tendenze e confrontarle con quelle di utilizzo dell’app permette di focalizzare al meglio anche tutti gli sforzi di comunicazione e gli investimenti marketing a favore dell’app.

Segmento Lingua: questo segmento può essere spesso molto simile al precedente, ma molto più preciso nella comprensione delle localizzazioni linguistiche più utilizzate e soprattutto per individuare eventualmente in quali lingue focalizzare i propri sforzi e investimenti, partendo dalle aree linguistiche che già più utilizzano e quindi già apprezzano il nostro prodotto.

Voti e Andamento Recensioni: queste metriche permettono di monitorare l’andamento della votazione media ottenuta nel corso del tempo dalla vostra app. È molto interessante per vedere eventuali reazioni in termini di giudizi degli utenti in seguito al rilascio di aggiornamenti dell’app stessa. Inoltre, la piattaforma che si basa sul sistema operativo Android permette agli sviluppatori di dialogare con gli utenti che lasciano le recensioni e di fornire risposte ai loro commenti: una possibilità favolosa per instaurare un dialogo con i nostri utenti. Alcuni vi forniranno dei suggerimenti preziosissimi e delle esperienze d’uso a cui probabilmente non avevate minimamente pensato (Figura 10.24).

In generale, Google Play fornisce molte più informazioni quantitative rispetto alla piattaforma di Apple e permette una maggiore vicinanza ai propri utenti tramite la possibilità di risposta alle recensioni; una piattaforma più valida, che garantisce maggiori dati su cui ragionare e complementari rispetto all’App Analytics.

L’utilizzo delle dashboard fornite dagli store in modo del tutto gratuito è un inizio e quasi un “assaggio” di come possano essere interessanti tutte le informazioni di utilizzo, soprattutto da parte di Google Play, circa le installazioni attive. Questa metrica dovrebbe portarci immediatamente a pensare al motivo per il quale gli utenti abbandonano la nostra app e la disinstallano dai loro dispositivi: bisogna comprendere se lo fanno dopo averla usata a fondo oppure se la usano poco e l’abbandonano immediatamente.

Figura 10.24 – La schermata di riassunto delle valutazioni e delle recensioni degli utenti di un’applicazione in Google Play. Partendo da questa schermata potrete anche rispondere alle recensioni.

Questi sono dei primi quesiti che dovrebbero spingere chiunque punti su un’applicazione, anche se demoralizzato da risultati non eccezionali all’inizio, a credere in quello che ha sviluppato e nella bontà del progetto (altrimenti non avrebbe dovuto nemmeno intraprenderlo). Ora è il momento più critico: non bisogna farsi scoraggiare dai pochi download giornalieri, ma nemmeno esultare alla prime giornate con centinaia di installazioni. Certamente bisogna sfruttare la spinta iniziale della pubblicazione e dell’effetto novità e soprattutto comprendere che cosa funziona e che cosa meno e soprattutto come gli utenti la usano effettivamente. L’utilizzo di un software di App Analytics risulta essenziale e di vitale importanza soprattutto per coloro che puntano molto ai dispositivi iOS.

Come e che cosa misurare

La misurazione è il principio cardine di qualsiasi attività che si svolge sul digitale; sapere solo il numero di download e di aggiornamenti è un dato estremamente limitato. Non potete non conoscere come viene utilizzata la vostra applicazione, perché le app di successo sono quelle che vengono usate non solo al momento del download, ma anche in seguito per periodi più o meno lunghi. Se avete solo la prima informazione, state osservando il mondo dal buco di una serratura. State vedendo solo la punta di un iceberg e potreste trarre delle considerazioni completamente errate e prendere delle decisioni poco corrette.

Non esiste in assoluto una metrica più importante di altre (con l’eccezione di quelle basilari) e non ci si può affidare a formule matematiche precise: sarebbe troppo semplice, riuscirebbe a farlo anche il software stesso dell’App Analytics. I dati e le informazioni provenienti dalle Analytics, in particolare l’app, devono essere valutati e analizzati dalle persone e filtrati a seconda delle necessità e degli obiettivi prefissati. Il software di Analytics ha bisogno di persone che analizzino i suoi dati: l’Analytics necessita l’analisi, è ovvio, lo dice la parola stessa. I software delle Analytics sono come i cruscotti degli aeroplani moderni: tanti dati, tante informazioni in tempo reale e non, molti report testuali e grafici, ma se non ci fosse il pilota a tenere tutto sotto controllo e a reagire a seconda delle informazioni ricevute… io mi sentirei meno tranquillo su quell’aereo. Se a ciò aggiungiamo che stiamo pilotando mezzi innovativi che hanno fatto collaudi brevissimi o pressoché nulli e che intorno a noi ci sono migliaia di altri aerei che cercano di accaparrarsi il maggior numero di passeggeri, possiamo comprendere immediatamente che ci servono dei cruscotti con tante informazioni e almeno un pilota in grado di leggerle e interpretarle.

Le informazioni della Store Analytics le otterrete in automatico all’interno dei pannelli di gestione delle applicazioni fornite agli sviluppatori. I dati arriveranno in automatico. I dati dell’App Analytics invece si ottengono attraverso l’utilizzo di un software che, descrivendo tutto in modo molto semplice, funziona in parallelo alla vostra app e viene “chiamato” di volta in volta al verificarsi dei caricamenti delle schede dell’app o di determinati eventi impostati a livello di codice nell’app stessa. Va quindi aperto un account su piattaforme di terze parti, come quella di ShinyStat, e collegato il codice in modo che funzioni parallelamente e dialoghi con la vostra app. Allo stesso modo, dovrete installare dei pacchetti software aggiuntivi alla vostra app, degli SDK di terze parti, come quelli delle Analytics, per misurare perfettamente le conversioni delle differenti campagne. Progettate un sistema di misurazione composito, che ottenga informazioni da più direzioni: dagli app store, dall’App Analytics e dal tracking pubblicitario. Utilizzate gli eventi, per le app che necessitano la connettività, pensando banalmente a modelli di gioco come quello di Hay Day. Costruite un motore personalizzato di dati per comprendere al meglio come i vostri utenti stanno utilizzando il gioco: quanti giocatori hanno raggiunto il livello tre del vostro gioco? Quanti campi di grano hanno raccolto? Qual è il livello con il maggiore tasso di abbandono del gioco? Comprenderete immediatamente l’importanza di avere queste informazioni per poter migliorare la vostra app.

Dovete misurare tutto, come insegnava sapientemente Galileo, per cercare di comprendere al meglio come viene utilizzata la vostra app e come potete di conseguenza migliorare ulteriormente la sua usabilità. Ma potete anche capire meglio le dinamiche degli store in termini di posizionamento delle app e, anche solo indirettamente, la bontà dei vostri investimenti marketing a supporto della vostra applicazione.

In primo luogo, è importantissimo aver compreso completamente le metriche relative all’app e alla Store Analytics e il loro esatto significato: sono i vostri strumenti di lavoro e le vostre unità di misura e dovete quindi conoscerli senza alcuna titubanza.

Dovrete avere ben presenti, meglio se disponibili in un documento di specifiche tecniche ben conservato, le linee guida di come vengono acquisiti i dati dell’App Analytics e la descrizione di tutti gli eventi nonché i nomi delle schede impostati all’interno dell’applicazione.

Inoltre un buon analista deve gestire le interfacce e saper creare delle reportistiche ad hoc; dovete quindi sapere come segmentare i dati, in che modo gestire gli archi temporali e le comparazioni delle varie metriche. In molti casi dovrete ricorrere all’export delle informazioni e all’utilizzo dei fogli di calcolo (i soliti file .xls) per le analisi più approfondite e complesse che vi permetteranno di comprendere meglio le dinamiche della vostra app necessarie per studiare a fondo determinati fenomeni. E quando sarete dei maghi dei dati scoprirete le arcane tabelle pivot.

Infine dovete abbandonare le vostre convinzioni personali e cercare di immedesimarvi il più possibile nell’utilizzatore medio della vostra app: cercate di capire come la usa e che azioni compie e in quanto tempo. Ogni progetto è diverso e ha obiettivi differenti; per questo una metrica con determinati valori ha un senso e un’importanza molto forti per una determinata applicazione, mentre può fornire un’indicazione diametralmente opposta in un’altra app che è contestualizzata in modo differente e ha obiettivi diversi. Non esiste quindi un tempo medio di utilizzo ideale: ogni app dovrebbe avere il suo e questa metrica, come la maggior parte, va interpretata e analizzata. La cosa fondamentale è poi l’analisi dei trend e dei cambiamenti delle metriche nel corso del tempo: in seguito ad aggiornamenti dell’app negli store ma anche in relazione ad attività di comunicazione e di marketing di supporto. L’analisi temporale riveste un ruolo fondamentale. Nel caso abbiate più app differenti, pubblicate con obiettivi simili: è utilissimo confrontare anche le varie metriche dei gruppi delle applicazioni per notare se esistono delle differenze e soprattutto per comprendere quali siano i motivi di queste divergenze e scostamenti dei dati. Analizzate e comparate le performance della vostra app, anche nel caso la pubblichiate contemporaneamente per diversi sistemi operativi, e cercate anche in questo caso di capire se esistono differenze tra gli utilizzatori di Android e quelli di iOS.

È importante anche incrociare i dati forniti dagli store (soprattutto per Google Play) e analizzare quelli dell’App Analytics per capire meglio se sta cambiando la tipologia di utilizzatori della mia app, oppure segmentare meglio i nuovi utenti per sapere se il ciclo di vita della mia applicazione sta aumentando o meno con l’acquisizione di questi ultimi.

Di seguito, alcune casistiche reali di lettura dei dati e delle informazioni per una prima analisi comparativa.

Engagement/Riutilizzatori: una metrica che viene calcolata dai dati di base e indica gli utenti che riutilizzano la vostra applicazione.

Engagement = Utenti unici giornalieri – Installazioni.

È un dato molto importante per le app che dovrebbero ricevere un utilizzo continuativo, come potrebbe essere un’app del meteo. In questo caso l’engagement dovrebbe essere una linea che continua a crescere nel corso del tempo. Gli utenti che scaricano l’app la utilizzano in modo continuativo e, poiché i download dell’app portano sempre nuovi utenti, la curva cresce. Nel caso l’engagement non aumenti, ma rimanga costante o addirittura diminuisca, questo può significare una scarsa fidelizzazione degli utenti, un utilizzo meno continuativo di quanto immaginato e, probabilmente, una forte percentuale di utenti che disinstallano o hanno disinstallato la vostra applicazione. In Google Play avrete questi due dati con precisione e quindi potrete interpretare ancora meglio l’engagement.

Confronto Store Analytics vs App Analytics: analizzando i dati si costruiscono ipotesi e idee dei fenomeni che generano quelle informazioni. È sempre importante cercare di creare queste ipotesi non basandosi unicamente su un solo report ma testando l’ipotesi anche con altre metriche nel caso sia possibile, in particolar modo nella prima fase del lancio di un’applicazione.

Osserviamo un caso che mi è realmente accaduto: guardando semplicemente il dato del numero di download fornitomi dall’Apple App Store, rilevo un andamento decrescente che poteva allarmare molto e portare sfiducia appena dopo il lancio dell’app.

Figura 10.25 – Il grafico dei download di un’applicazione in vendita su Apple App Store che presenta un andamento negativo dopo un discreto successo iniziale.

Abbiamo però analizzato più a fondo l’andamento di questa applicazione che presenta chiaramente una diminuzione dei download. In compenso il grafico mostra che il numero di utenti unici giornalieri continua ad aumentare, segno che coloro che hanno scaricato il vostro software continuano a utilizzarlo in modo frequente. Anche le sessioni e le schede viste sono in aumento, tutti segnali che l’app veniva apprezzata dagli utenti che la usavano anche in profondità (Figure 10.26 e 10.27).

Un’altra metrica, infine, che ci confermava il fatto che l’app stava riscuotendo successo e veniva realmente utilizzata era, sempre in questo caso, il tempo medio di utilizzo dell’applicazione e anche qui il dato era in aumentato. L’app veniva riutilizzata e gli utenti la usavano anche più a lungo, tutti segnali che rendevano la diminuzione dei download molto meno preoccupante (Figura 10.28).

Figura 10.26 – Grafico di comparazione degli Utenti Unici Giornalieri vs Installazioni.
Il divario tra le due curve si sta ampliando, segno che aumenta l’engagement dell’applicazione: un segnale estremamente positivo.

Figura 10.27 – Il grafico dell’engagement della stessa applicazione è in aumento: un segnale molto positivo.

Figura 10.28 – Andamento della durata media delle sessioni della stessa applicazione.
Anche questa metrica è in aumento ed è un segnale molto positivo per il futuro.

Si è deciso quindi di provare ad aumentare la base utenti con campagne mirate di advertising e supporto di un mini-sito web dedicato. L’applicazione ha poi incrementato enormemente le vendite grazie al modello di in-app purchase e al fatto di avere un’utenza molto fidelizzata e che realmente utilizza il software. Un’analisi senza i dati dell’App Analytics, ma solo con quelli dello store, avrebbe forse fatto desistere e certamente scoraggiato il gruppo di lavoro del progetto e il suo ideatore (e finanziatore). I dati di utilizzo invece hanno fatto credere nel progetto e anzi intraprendere azioni a supporto ancora più impegnative rispetto a quanto era stato precedentemente pianificato.

Oggetti Multimediali in-app: Video e Audio App Analytics

Moltissime app utilizzano al loro interno delle funzionalità multimediali, banalmente dei video e/o delle tracce audio. È il caso dell’app di Video Mediaset, che sfrutta abbondantemente e prevalentemente i video al suo interno. Gli analisti ottengono tutte le metriche dell’App Analytics standard e hanno anche il dettaglio di visione dei video e del singolo video attraverso gli strumenti di in-app Video Analytics.

La Video Analytics pone al centro dell’analisi il singolo video. Il video è un oggetto multimediale per lo più on demand, ovvero dove l’utente può interagire col video stesso mettendolo in pausa, rivedendo alcune porzioni e saltandone altre oppure rivedendolo più volte.

La Video Analytics presenta in primo luogo la reportistica dell’intero aggregato di offerta video presente all’interno di una determinata applicazione, fornendo delle metriche base essenziali per comprendere la fruizione dei video da parte dei propri utenti.

Video Visti: è il numero di video visualizzati dagli utenti. Indica l’aggregato di video che hanno avuto almeno una visualizzazione da parte di un dispositivo mobile.

Visualizzazioni: per “visualizzazione” si intende una porzione di video caricata dal dispositivo mobile, a prescindere dal fatto che esso sia stato visualizzato interamente o solo parzialmente. Il termine “visualizzazioni” indica il numero di volte che la singola porzione del video in esame è stata visualizzata nell’intervallo temporale considerato. Per un’analisi puntuale, precisa e intuitiva delle visualizzazioni, ho contribuito personalmente all’interno di ShinyStat a creare lo spettro di visione, un brevetto dell’azienda italiana, pioniere nella Video Analytics in profondità a livello mondiale.

Visitatori unici assoluti/giornalieri video: per “visitatore unico assoluto” si intende il visitatore/dispositivo mobile che accede al video per la prima volta in assoluto. Di conseguenza, quando un utente apre un video che non ha mai visto prima, viene rilevato come “visitatore unico assoluto”. Se l’utente effettua successivamente un altro accesso al video, utilizzando lo stesso dispositivo, viene riconosciuto e quindi non più rilevato come “visitatore unico assoluto di quel video”.

Figura 10.29 – Grafico e dettaglio tabellare delle metriche globali di visione di un’app con contenuti video.

Percentuale di completamento video: questa metrica indica il rapporto tra il numero di “visitatori unici assoluti” e il numero di “visitatori unici assoluti che hanno completato il video”. Percentuale di completamento del video = Visitatori Unici Assoluti / Visitatori Unici Assoluti che hanno completato il video. Per “visitatore unico assoluto che ha completato il video” si intende un visitatore unico assoluto che, quando ha visto il video per la prima volta, ne ha visionato almeno il 90%. Il dato, quindi, fornisce una stima di quanti visitatori unici hanno visualizzato almeno il 90% del video.

Inoltre è possibile e molto utile analizzare l’andamento dei singoli video cercando di capire se determinati fenomeni di pubblicazione ed editoriali influenzino o meno le modalità di visione. Collegate a questa metrica ci sono anche quelle del tempo medio di visione del video e, cumulato, del tempo totale di visualizzazione del o dei video.

La particolarità dell’oggetto video e delle sue modalità di fruizione comandate dall’utente (on demand) necessitano di un’analisi approfondita dell’oggetto video che può fornire idee e informazioni molto dettagliate: lo spettro di visione del video.

Il grafico della Figura 10.30 presenta una visualizzazione lineare: moltissimi utenti cominciano a visualizzare il video ma, mano a mano che passa il tempo, smettono di vederlo e sono solo pochi quelli che arrivano fino in fondo.

Alcune tipologie di video, molto spesso quelle di maggior successo, presentano, però, una visualizzazione non lineare, determinata proprio dal fatto che è l’utente che controlla la visione e la personalizza a piacere.

Figura 10.30 – Grafico e spettro di visione di un video con visualizzazione lineare.

Figura 10.31 – Spettro di visione e grafico di un video non lineare.

Come si evince facilmente dall’immagine della Figura 10.31 la visualizzazione di quel filmato non è stata lineare. Il video raggiunge dei picchi di visualizzazione e di attenzione in determinate porzioni create dagli utenti che si fanno una sorta di replay on demand e visualizzano più volte una sezione del video. Esempi come questo sono classici in rete.

La corretta lettura di visione da parte degli utenti e l’interpretazione censuaria del video può fornire degli spunti e delle idee a livello editoriale anche per la semplice titolazione dei video o per la navigazione incrociata degli stessi.

Dai report all’azione: il processo di miglioramento continuativo

Galileo non è ricordato tanto per l’invenzione del cannocchiale: la sua scoperta più importante non fu un oggetto, bensì il metodo scientifico sperimentale, che si adatta perfettamente a qualsiasi sistema di misurazione di qualunque contenuto digitale.

Nel metodo scientifico sperimentale, che viene utilizzato per scoprire nuove regole fisiche dei fenomeni naturali (e virtuali), la misurazione non è a valle dell’esperimento, bensì a monte: Galileo ha compreso che bisogna osservare e misurare un fenomeno per poter esprimere delle ipotesi, fare ulteriori esperimenti (ovvero modifiche per la vostra applicazione o azioni di comunicazione e marketing) e quindi validare l’ipotesi o provare altri esperimenti che confortino l’ipotesi stessa o la smentiscano. Comunque vada, avrete acquisito conoscenza e cercherete di ottenere gli stessi successi in futuro oppure evitare i medesimi errori… l’esperienza non ha prezzo.

La misurazione è quindi al centro del metodo galileiano, che considero ancora attualissimo e forse ancora più valido nell’ambiente digitale, dove tutto o quasi è perfettamente misurabile.

Oltre allo scienziato pisano, un’altra figura ancora attualissima, il cui metodo si adatta perfettamente all’ambiente di lavoro digitale, è quella di Edward Deming, l’americano più famoso in Giappone, colui che portò il processo di miglioramento continuativo trasformandolo in “kaizen”, in linea con la precisa cultura del Paese del Sol Levante. Questo termine giapponese, che in italiano suona purtroppo un po’ strano, deriva dalle due parole: “kai”, che significa cambiamento e “zen” inteso come buono; il cambiamento verso il buono, verso il meglio, il cercare di migliorarsi e di superarsi sempre.

Esistono interi manuali che parlano del kaizen io ho personalmente sempre utilizzato questo metodo in ogni ambito del mio lavoro in campo digitale, perché credo che sia uno dei migliori in assoluto. Possiamo descrivere la sua applicazione in ambito digitale:

Modifche incrementali: devo utilizzare il più possibile i test A/B per comprendere quali modifche funzionano e se la situazione migliora. Per questo motivo i miei cambiamenti saranno incrementali e isolati in modo da comprendere esattamente quale sia stata la variabile che ha condizionato il cambiamento.

Processo circolare: il processo di miglioramento continuativo non si deve arrestare mai: devo continuare a tendere verso il meglio, superare ogni volta me stesso e crescere imparando anche dagli errori; molto in linea con tutta la cultura nipponica.

Chiunque deve sperimentare: dovete sempre cercare delle nuove soluzioni, qualcosa che non avete mai provato in passato; ogni persona del gruppo di lavoro può proporre la sua idea che deve essere testata per capire se porta un miglioramento o meno; chiunque può innescare il kaizen all’interno di un progetto digitale.

Plan-Do-Check-Act: il ciclo di Deming o PDCA Cycle è il mantra del processo di miglioramento continuativo. In primo luogo devo pianifcare la mia modifca o l’introduzione di un’innovazione, attraverso il “plan” decido cosa fare e stabilisco che cosa attendermi dalla modifca o dall’introduzione della novità. In seguito devo seguire il piano e agire, facendo ciò che ho stabilito e affrontando la fase del “do”. Quindi misuro e verifco che cosa ha apportato la modifca o l’implementazione innovativa, eseguo cioè il “check” di ciò che ho pianifcato. Infne agisco e decido se mantenere o scartare la modifca nella fase dell’“act”. Il processo è circolare e quindi una volta terminato devo pianifcare un ulteriore cambiamento.

Il processo di miglioramento continuativo applicato alle app è molto semplice: prendiamo come esempio un’applicazione editoriale, il cui scopo principale è l’erogazione di banner pubblicitari su dispositivi mobili, con la quale l’editore pubblica un annuncio per ogni scheda che ruota ogni 30 secondi.

L’obiettivo principale dell’app sarà quello di ottenere un numero molto elevato di schede viste e nel contempo un tempo medio di permanenza sulla scheda vista abbastanza elevato, così che l’editore stesso possa erogare un numero elevato di banner a rotazione.

Dopo aver sviluppato un’applicazione, si sceglie di fare delle modifiche alla scheda dell’articolo spostando il menu che collega altri articoli dalla parte superiore dell’interfaccia alla parte inferiore. Prima di aggiornare le modifiche, è fondamentale individuare le metriche fondamentali delle “schede viste” e del “tempo medio di permanenza per scheda”. Si effettua l’aggiornamento e, dopo un adeguato lasso temporale, si esegue nuovamente la misurazione: nel caso in cui le metriche abbiano subito un incremento la modifica verrà mantenuta, in caso contrario si tornerà velocemente alla versione precedente la modifica.

In entrambi i casi, continuerò comunque a cercare di migliorare sempre quelle due metriche che sono decisive, migliorando l’esperienza dell’utente in base alle sue reazioni in conseguenza delle modifiche apportate.

Di volta in volta avrete una vostra strategia: cercate di isolare il più possibile l’effetto delle modifiche e di tenere sempre in primo piano la misurazione di tutto quello che fate. In questo modo non è garantito il successo della vostra idea, ma certamente capirete una parte dei motivi di insuccesso della stessa. Anche gli errori aiutano molto. La prossima volta che svilupperete un’app avrete fatto tesoro di tutta questa esperienza e certamente non commetterete gli stessi errori. Avete innestato il kaizen, adesso non vi ferma più nessuno!

63. Marketing payback. Il contributo del marketing alla redditività dell’impresa, di Robert Shaw e David Merrick.

64. Oggi Pisa è una delle città con maggiore copertura di wi-fi pubblico in Italia grazie a un progetto lungimirante della pubblica amministrazione a favore dei turisti, degli studenti e di tutti i cittadini.

65. Le aziende che forniscono strumenti di Analytics offrono il loro servizio in modalità SAAS: “Software As A Service”.

APPENDICE

FUTURO

La rivoluzione portata dall’introduzione dei dispositivi mobili è solo all’inizio e in forte evoluzione. In questa sezione finale del libro cercheremo di comprendere alcune tendenze già in atto che trasformeranno ancora di più il nostro modo di vivere, in continuo contatto con la tecnologia, dove la distinzione tra digitale e analogico sarà sempre più difficile da percepire e i dispositivi mobili saranno il ponte di unione del mondo digitale con quello fisico.

Alcune tendenze in atto potrebbero trasformarsi ulteriormente e cambiare con l’introduzione di nuove tecnologie, ma molto probabilmente gli smartphone saranno sempre al centro di tutta la tecnologia che in breve tempo ci circonderà. Dai gadget da indossare come orologi e occhiali ai vestiti smart, dalla domotica alle automobili connesse alla rete, i cellulari costituiranno il centro di raccordo tra tutte queste tecnologie in quanto sono i più portabili e restano sempre con noi.

Cercherò di delineare quindi le seguenti tendenze già in atto che, dal mio punto di vista, porteranno dei forti cambiamenti anche in termini sociali e di stili di vita di comportamento dell’uomo.

Fare business con i dispositivi mobili e con le app di terze parti.

Le app per il tracking delle persone.

Le app per Internet delle cose.

App e mobile payment.

Fare business con i dispositivi mobili e con le app di terze parti

Non tutti potrebbero avere un’idea o un’attività adatta alla realizzazione di un’applicazione, soprattutto in relazione all’investimento necessario e al ritorno dello stesso. Questo non significa che si debba completamente ignorare questo fenomeno, in quanto spesso è possibile inserirsi nel grande business delle applicazioni anche senza averne una. Prendiamo un caso classico del settore turistico: come può un piccolo hotel a tre stelle sfruttare l’utilizzo dei dispositivi mobili per promuovere la propria struttura e comunicare coi propri clienti? L’hotel in questione, oltre al classico sito web, dovrebbe avere i seguenti ingredienti della sua strategia dedicata ai dispositivi mobili. Dovrebbe avere addirittura una vera e propria strategia “mobile only” distinta da quella web:

Creazione di un m-site usabile.

Inserimento in app di terze parti.

Controllo del posizionamento sulle mappe.

Gadget antiroaming per i clienti.

Marketing e comunicazione digitale in tempo reale (o appena dopo la cena).

Marketing preventivo one-to-one.

Creazione di un m-site usabile: per una qualsiasi struttura in ambito turistico, tutti i servizi al dettaglio dovrebbero avere un m-site, come già analizzato in questo libro. Il sito deve essere chiaramente responsive per la parte dedicata ai tablet, dove dovrete testare l’usabilità per il raggiungimento della conversione, mentre esso deve andare oltre il concetto di responsive design e divenire adaptive design quando lo pensiamo dedicato agli smartphone. Fondamentale l’inserimento di due funzionalità che hanno meno senso sulla versione desktop: nell’m-site avrò due pulsanti molto evidenti, il primo che farà partire una telefonata verso l’hotel, il secondo che avvierà le mappe all’interno del dispositivo dell’utente con l’indicazione di arrivo preimpostata verso la struttura ricettiva. Queste due componenti sono essenziali, oltre a quella di un sistema di prenotazione usabile, semplice, veloce e soprattutto fruibile da smartphone. Se poi ne voleste incentivare l’uso, l’idea dell’offerta per la notte stessa via smartphone nel corso del tempo potrebbe essere una buona strategia.

Inserimento in app di terze parti: per il nostro hotel a tre stelle la realizzazione di un’applicazione potrebbe essere onerosa per un ritorno molto limitato in termini ricettivi. Esistono però moltissime applicazioni utilizzate da milioni di utenti, per cui è bene verificarne l’opportunità o la propria presenza. Due esempi su tutti sono l’applicazione (e il sito desktop e mobile) di TripAdvisor e di Booking.com. La presenza sul primo portale è gratuita ed è quasi una sorta di social network di strutture ricettive, mentre il secondo è un esempio di Online Travel Agency, uno dei più conosciuti e utilizzati. Questi sono solo due esempi: dovreste conoscere da soli quali canali utilizzano i vostri utenti. Esistono app turistiche verticali dove potete essere presenti, suddivise per area geografica oppure per tipologia di vacanza; ci sono OTA che gestiscono alcune categorie di viaggiatori e altre specializzate nella prenotazione per la notte stessa. Esistono migliaia di app in ambito turistico. Il mio suggerimento è di scaricarle voi stessi e provare a vedere come e quali strutture sono presenti all’interno dei vostri concorrenti, decidendo, in base anche al costo eventuale richiesto, se entrare o meno all’interno di queste applicazioni di terze parti. La vostra presenza all’interno di questi ecosistemi vi permette di raggiungere alcune categorie di pubblico molto fidelizzate che si spostano da un hotel a un ristorante leggendo recensioni e prenotando con tablet e smartphone. Ignorare e non gestire la propria presenza all’interno di quelli più diffusi vi preclude tutta una serie di soggetti, e saranno sempre di più nel tempo, che utilizzano queste nuove modalità attraverso i loro dispositivi mobili prima, durante e dopo la vacanza.

Controllo del posizionamento sulle mappe: dovremo controllare che la nostra struttura alberghiera sia posizionata correttamente all’interno delle mappe che sono presenti nei dispositivi mobili. Questo è ancora più importante per tutte le attività locali aperte al pubblico, come bar, ristoranti, fioristi, farmacie. Controllate la vostra posizione e, nel caso non sia corretta, usate gli strumenti messi a disposizione dai gestori delle mappe per correggere l’ubicazione. Non controllate solo Google Maps, ma anche le mappe di Apple e quelle di Microsoft, così come Waze e Pagine Gialle e così via.

Gadget antiroaming per i clienti: il nostro hotel a tre stelle riceve molti clienti stranieri, tutti dotati di potentissimi smartphone, ma anche di potentissime tariffe di traffico dati all’estero. Quasi nessuno straniero lascia accesa la rete dati quando è all’estero, ovvero in modalità roaming, a causa delle tariffe spesso proibitive. Cercheremo di andargli incontro e insieme ai classici depliant cartacei faremo un piccolo hotspot wi-fi dove gli utenti potranno accedere per scaricarsi mappe offline in PDF, magari calibrate con un GPS offline, oltre a numeri utili, itinerari, zone da vedere ecc. Non solo questo verrà apprezzato e utilizzato, ma probabilmente rimarrà nei loro smartphone per molto tempo anche dopo il loro ritorno. Magari qualcuno di loro passerà il vostro PDF in un altro telefono di un suo amico, che sarà il nostro prossimo ospite dell’hotel.

Marketing e comunicazione digitale in tempo reale: gli smartphone e i tablet sono continuamente presenti nelle camere del nostro hotel. I nostri clienti vanno sui social network, navigano in rete spesso su portali turistici della zona o relativi alla località dove si trova la nostra struttura. Abbiamo l’opportunità di interagire con loro anche sul digitale e non semplicemente alla reception. Un esempio banale è la pagina di accesso con username e password per accedere alla rete wi-fi dell’hotel. Spesso una tristissima pagina bianca e vuota. Il nostro hotel l’ha arricchita con i collegamenti ai propri social network e ai siti turistici della zona, mettendo un link speciale per lasciare un commento o una recensione su TripAdvisor e su Facebook e promuovendo un piccolo contest fotografico con Instagram, offrendo aperitivi ai clienti più creativi. Cercate di stimolare in modo intelligente queste attività perché le recensioni e i commenti sui social sono ormai vitali per qualsiasi struttura alberghiera. Molte persone infatti lasciano le recensioni spesso in caso di eventi negativi, mentre sono meno propense, se non stimolate, a lasciare giudizi in caso di esperienze positive (se non in caso di rarissime eccellenze). Questo anche perché il ricordo dopo la permanenza nella nostra struttura (e nel ristorante) svanisce. Cerchiamo quindi di stimolare il contenuto e i giudizi mentre i nostri clienti stanno ancora godendo del nostro servizio, quando occupano ancora le stanze del nostro hotel e mentre sono ancora seduti nel nostro ristorante. Promuovendo un banalissimo concorso, con in palio un paio di bicchieri di bollicine per la foto più bella della camera del nostro albergo su Facebook o Instagram, faremo sapere a tutti gli amici dei nostri clienti che in questo momento si trovano ospiti della nostra struttura, diventando così un efficace veicolo di marketing. Cercate di agire sul digitale in tempo reale, quando i vostri clienti stanno ancora godendo della bellezza del vostro servizio.

Marketing preventivo one-to-one: il nostro hotel a tre stelle è piccolo, ma la cura verso i nostri clienti è spasmodica: tutte le prenotazioni ci arrivano via Internet e in molti casi riceviamo direttamente dai clienti i loro contatti social e la loro mail. In questo modo possiamo verificare se esprimono determinati interessi e cercare di coccolarli fin dal primo momento. Adorano la cioccolata fondente? Gli faremo trovare dei cioccolatini di cacao trinitario aromatico. Amano il blu? Sceglieremo magari i copriletto di quel colore. Riuscire a stupire i clienti e rendere un’esperienza unica e personalizzata è uno dei punti di forza del nostro hotel. Spesso riceviamo il “mi piace” dai nostri clienti ancor prima che arrivino nella nostra struttura e riusciamo a dialogare con loro direttamente sui social, anche mentre soggiornano da noi.

Questo caso studio è un classico per il settore turistico ma esistono talmente tante applicazioni che, anche nel vostro settore, potrebbero esserci delle interessanti opportunità come quelle utilizzate precedentemente. Provate a cercare app relative alla vostra attività e vedere se potete inserirvi all’interno; un po’ di tempo per cercare vi costerà pochissimo impegno in rapporto a quanto l’apertura di un canale digitale di utenti come quello delle app potrebbe portare alla vostra attività.

Le app per il tracking delle persone

Un’altra evoluzione futura già in atto è l’utilizzo di applicazioni combinate con degli accessori, come braccialetti frequenzimetri e orologi, ma anche bottoni e scarpe che permettono di rilevare tutta una serie di dati biometrici dell’individuo e fare un vero e proprio tracking. Parliamo per esempio delle banali app che si attivano ogni volta che sentono un rumore durante le ore notturne e registrano in modo che ognuno di noi possa riascoltare ciò che dice durante il sonno, oppure del braccialetto della Jawbone che, con la sua applicazione Up, permette di rilevare la differenza tra sonno leggero e sonno profondo di un individuo, per capire se un soggetto si sveglia durante la notte. Lo sviluppo sta accelerando sempre di più: partito da applicazioni molto famose come Runtastic, ora è arrivato in campo medicale e si stanno compiendo degli studi e realizzando decine di app per monitorare in modo più o meno approfondito e poco invasivo innumerevoli soggetti con svariate caratteristiche biomediche e di stress psicofisico. Samsung ha costruito un vero e proprio pacchetto hardware e software integrato ai propri dispositivi mobili, il cosiddetto “Samsung Health”, costituito da un pacchetto di protocolli con i quali comunicare informazioni medicali rilevate da sensori esterni al dispositivo stesso.

Quello della misurazione delle proprie attività quotidiane è un fenomeno molto interessante e in rapida espansione: bisognerà affrontarlo molto da vicino perché porterà con sé dei vantaggi enormi e al contempo qualche risvolto delicato. È un mondo in continua evoluzione e difficile da prevedere, ma tra pochissimo tempo verremo invasi da centinaia di gadget da indossare che potranno essere connessi al nostro dispositivo mobile e dialogare con lo stesso salvando al loro interno tutta una serie di informazioni importanti. Personalmente, ho già testato alcune soluzioni e, da patito del tracking di qualsiasi cosa sia digitale, non posso che dirmi entusiasta circa le possibilità di self tracking, ormai a disposizione di tutti. Una maggiore informazione del proprio corpo e delle proprie abitudini porta la maggior parte dei soggetti ad assumere comportamenti migliori. Da quando indosso il braccialetto che misura i miei movimenti quotidiani, per esempio, tendo ad alzarmi di più dalla sedia, a telefonare camminando, a fare due passi a piedi in più rispetto al solito per ottenere una maggiore distanza percorsa alla fine della giornata. Nelle Analytics personali bisogna comportarsi così, seguendo il processo di miglioramento continuativo, impostando degli obiettivi comportamentali e verificando quando e come si riesce a raggiungerli. La misurazione del proprio organismo comporta una maggiore consapevolezza della propria forma fisica; ci rendiamo conto dei comportamenti sbagliati che assumiamo e la misurazione porta quindi consapevolezza, anche se il libero arbitrio dell’individuo rimarrà inviolato.

Le app per Internet delle cose

Il mondo intorno a noi si trasformerà in modo radicale, in particolare all’interno delle nostre abitazioni e in ambito lavorativo. Il mondo fisico sarà sempre più connesso con quello digitale e la distinzione tra online e offline sempre più sfumata e indefinita. Si parla ormai da molti anni di Internet of things o Internet delle cose, ovvero la possibilità di connettere alla rete oggetti di qualsiasi tipologia purché dotati di accesso alla rete e di energia elettrica. Ma l’Internet of things è rimasto confinato a poche soluzioni molto costose e a volte quasi sotto forma di prototipo. I dispositivi mobili stanno giocando un ruolo cruciale nella diffusione reale della rete interconnessa di oggetti. Il nostro smartphone è sempre più un telecomando vero e proprio di differenti dispositivi domestici: controllo la televisione, navigo i menu della consolle domestica, controllo la temperatura degli ambienti, verifico l’impianto di videosorveglianza e così via. Siamo solo all’inizio di una vera e propria rivoluzione del controllo e monitoraggio a distanza di qualsiasi cosa. I QR code permettono inoltre di spostare l’utente dall’offline all’online in qualsiasi contesto si trovi e senza nemmeno la necessità di essere collegato alla rete. Abbiamo già visto gli esempi di un utilizzo intelligente nel progetto Condom08 della municipalità di Stoccolma. Un altro caso studio classico è quello di Tesco, un’importante catena della grande distribuzione, che ha introdotto un nuovo modo di fare la spesa in Corea del Sud. Tesco acquista delle affissioni tradizionali nella rete metropolitana nazionale ma, anziché messaggi pubblicitari, pubblicizza i propri scaffali esponendo i vari prodotti in modo visuale e con il prezzo. Accanto a ogni singolo pezzo c’è un QR code che, utilizzato con l’app di Tesco, permette di aggiungere automaticamente e rapidamente il prodotto al carrello, completando così l’acquisto sullo store online della catena di distribuzione. L’app e i QR code hanno avuto un successo straordinario in termini di utilizzo, di utenti registrati e soprattutto di fatturato, permettendo a Tesco di raggiungere la prima posizione come GDO online nel paese asiatico con livelli di fatturato stratosferici. Ciò è stato possibile anche grazie all’elevata alfabetizzazione informatica degli utenti, all’alta urbanizzazione e quindi a una logistica rapidissima e alla compressione del tempo dei lavoratori coreani. La trasformazione del “tempo di attesa” (in metropolitana) in “tempo di spesa” è stata resa possibile dai dispositivi mobili. Siamo solo all’inizio di un nuovo modo di ingaggiare i consumatori utilizzando sistemi di promozione tradizionali, come la cartellonistica in metropolitana corredata di QR code. Ma non è appiccicando un semplice codice quadrato alla vostra comunicazione che otterrete i risultati sperati; cercate di farlo in modo intelligente e nuovo non utilizzando il mezzo tradizionale statico e aggiungendovi solo la semplice introduzione di un QR code.

In futuro, le app e i dispositivi mobili saranno sempre più interconnessi alle cose, anche attraverso il sistema di collegamento tra NFC e RFID che abbiamo spiegato nella sezione della sensoristica. Si stanno già sperimentando i primi prodotti alimentari che avvisano l’app quando sono prossimi alla scadenza, frigoriferi che dialogano con il consumatore, suggerendo ricette in base al proprio contenuto e compilando automaticamente la lista della spesa. Il 13 gennaio 2014 Google ha comprato per 3,2 miliardi di dollari in contanti l’azienda Nest, una delle imprese più innovative al mondo nella creazione di termostati intelligenti e rilevatori di CO_2 e allarmi antifumo. La missione della Nest è di rendere user friendly alcuni strumenti molto freddi e anonimi come i termostati, puntando sull’analisi dei dati per ottimizzare il risparmio energetico attraverso l’interazione con l’utente e il monitoraggio costante della qualità dell’aria che respiriamo. Tutte tematiche, queste, molto attuali, che verranno rivoluzionate nel prossimo futuro; in questo senso si capisce l’ingente investimento di Google anche nel settore del digitale.

App e mobile payment

Gli smartphone sono sempre in tasca e sono collegati a un conto telefonico, così come possano essere abilitati dalle carte di credito. Pensiamo solo a tutte le app che abbiamo acquistato. Per questo motivo è da ormai molto tempo che i telefonini vengono individuati come potenziali dispositivi per il pagamento. Quando lavorai un anno presso la Commissione Europea a Bruxelles, uno degli argomenti nei quali venni maggiormente coinvolto fu proprio quello delle transazioni elettroniche e degli strumenti di pagamento durante gli acquisti online[66]. Già all’epoca i cittadini svedesi potevano pagare tutti i taxi con il loro dispositivo mobile. Tutti i tentativi però di rendere delle vere e proprie carte di credito i nostri dispositivi non hanno avuto un successo su larga scala fino all’avvento degli ultimi modelli di smartphone, dotati di tecnologia NFC, e in grado quindi di attivare degli RFID o altri dispositivi NFC, creando una vera e propria comunicazione peer-to-peer molto protetta. Un tipo di comunicazione e protocollo già utilizzato anche in alcune carte di credito, i cosiddetti borsellini elettronici. Costruite per piccoli importi, queste carte permettono di accreditare e passare denaro elettronico da una carta a un’altra tramite l’utilizzo di un dispositivo. Ora, con l’NFC questo sistema potrebbe espandersi a macchia d’olio. Si potrebbe scrivere un intero libro anche su questi argomenti e sulle differenti possibilità applicative. Siamo solo all’inizio: lo smartphone verrà sempre più utilizzato anche come una carta di credito.

In generale, i telefonini del futuro sostituiranno sempre di più tutti gli oggetti che adesso custodiamo nel portafoglio. Oltre che come strumento di pagamento, lo smartphone può contenere biglietti elettronici per viaggiare su aerei, treni e qualsiasi mezzo di trasporto. Possiede al suo interno i nostri abbonamenti ai mezzi di trasporto urbano e potremo aprire i tornelli della metro semplicemente “strisciando” il nostro dispositivo mobile. Esso conterrà tutte le fidelity card in un unico luogo e questo aspetto apre delle inedite prospettive di real time marketing per chiunque faccia uso di carte di fedeltà, prima fra tutte la grande distribuzione organizzata. Lo smartphone è quindi il portafoglio del futuro, ma lo è già quasi del presente. La foto della nonna e del figlio sono già in copertina, tutto il resto sta solo per arrivare.

66. Tra luglio 2000 e giugno 2001, ho vinto una Internship presso la Commissione Europea dove, tra le altre cose, ho scritto la mia tesi di laurea: “La tutela del consumatore nel mercato digitale”.

Nella stessa collana

In tutte le librerie e su www.hoepli.it

Nella stessa collana

In tutte le librerie e su www.hoepli.it

Nella stessa collana

In tutte le librerie e su www.hoepli.it

Nella stessa collana

In tutte le librerie e su www.hoepli.it

Informazioni sul Libro

Creare un’applicazione, metterla negli store e pensare che, magicamente, la scarichino in milioni di persone è come fermarsi a una stazione di servizio, comprare un biglietto della lotteria e credere di diventare milionari.

La domanda di applicazioni è in fortissima e inarrestabile crescita, le app di maggiore successo generano milioni di dollari che vengono guadagnati (al 70% circa) dagli sviluppatori, ma i mercati delle applicazioni sono estremamente concorrenziali, velocissimi e in continua trasformazione: una buona idea non è più suffi ciente per emergere, è necessario avere una strategia ben precisa e delineata fi n dall’inizio.

Questo libro non è un manuale di codice per sviluppare applicazioni, né una guida per la costruzione di interfacce grafi che: questo è un manuale strategico per la realizzazione di app di successo; una guida che parte dall’analisi dell’idea e della concorrenza fi no alla misurazione delle performance attraverso strumenti di analytics. Scritto in modo semplice e ricco di esempi, accessibile a tutti anche a chi non è un programmatore o un grafi co, questo è il libro per tutti coloro che vorrebbero capire come monetizzare il proprio business con le app, ma anche molto semplicemente per chiunque desideri curiosare nel mondo che sta dietro un’icona quadrata di un centimetro e scoprire quanto lavoro ci sia per realizzare un’app di successo.