Monetizzazione con Gestione API di Azure
SI APPLICA A: Tutti i livelli di Gestione API
Le API Web moderne sono alla base dell'economia digitale. Forniscono la proprietà intellettuale (IP) di una società a terze parti e generano ricavi da:
- Creazione di pacchetti IP sotto forma di dati, algoritmi o processi.
- Consentire ad altre parti di individuare e utilizzare indirizzi IP utili in modo coerente e senza attriti.
- Offerta di un meccanismo per il pagamento diretto o indiretto per questo utilizzo.
Un tema comune tra le storie di successo dell'API è un modello aziendale integro. Il valore viene creato e scambiato tra tutte le parti, in modo sostenibile.
Le start-up, le organizzazioni consolidate e tutti gli elementi in-between in genere cercano di trasformare digitalmente a partire dal modello di business. Le API consentono di realizzare il modello di business, consentendo un modo più semplice e più conveniente per il marketing, l'adozione, l'utilizzo e il ridimensionamento dell'IP sottostante.
Le organizzazioni che pubblicano la prima API devono affrontare un set complesso di decisioni. Mentre la piattaforma azure Gestione API esegue l'escalation dei rischi e accelera gli elementi chiave, le organizzazioni devono comunque configurare e creare l'API in base al proprio modello tecnico e aziendale unico.
Sviluppo di una strategia di monetizzazione
La monetizzazione è il processo di conversione di qualcosa in denaro, in questo caso il valore dell'API. Le interazioni api in genere coinvolgono tre parti distinte nella catena di valori:
Le categorie di strategia di monetizzazione delle API includono:
Strategia di monetizzazione delle API | Descrizione |
---|---|
Gratuito | Un'API facilita l'integrazione aziendale, ad esempio la semplificazione di una supply chain. L'API non è monetizzata, ma offre un valore significativo abilitando l'efficienza dei processi aziendali sia per il provider api che per il consumer di API. |
Paga al consumatore | I consumer di API pagano in base al numero di interazioni che hanno con l'API. Questo approccio è incentrato su questo documento. |
I consumatori vengono pagati | Ad esempio, un consumer di API usa l'API per incorporare annunci nel proprio sito Web e riceve una quota dei ricavi generati. |
Monetizzazione indiretta | La monetizzazione delle API non è determinata dal numero di interazioni con l'API, ma tramite altre fonti di ricavi facilitate dall'API. |
Nota
La strategia di monetizzazione è impostata dal provider di API e deve essere progettata per soddisfare le esigenze del consumer dell'API.
Poiché un'ampia gamma di fattori influisce sulla progettazione, la monetizzazione delle API non è una soluzione adatta a tutte le dimensioni. La strategia di monetizzazione differenzia l'API dai concorrenti e ottimizza i ricavi generati.
I passaggi seguenti illustrano come implementare una strategia di monetizzazione per l'API.
Passaggio 1: Comprendere il cliente
Eseguire il mapping delle fasi del percorso probabile dei consumer dell'API, dalla prima individuazione dell'API alla scalabilità massima.
Ad esempio, un set di fasi cliente può essere:
Fase cliente Descrizione Analisi Abilitare il consumer di API per provare l'API con costi e attriti zero. Implementazione Fornire accesso sufficiente all'API per supportare il lavoro di sviluppo e test necessario per integrarlo. Anteprima Consentire al cliente di avviare l'offerta e comprendere la domanda iniziale. Utilizzo iniziale della produzione Supportare l'adozione anticipata dell'API nell'ambiente di produzione quando i livelli di utilizzo non sono completamente comprensibili e potrebbe essere necessario un approccio avverso al rischio. Crescita iniziale Consentire al consumer dell'API di aumentare l'utilizzo dell'API in risposta a una maggiore domanda da parte degli utenti finali. Ridimensiona Incentivare il consumer dell'API a eseguire il commit a un volume di acquisto superiore quando l'API raggiunge costantemente livelli elevati di utilizzo ogni mese. Crescita globale Ricompensare gli utenti dell'API che usano l'API su scala globale offrendo il prezzo all'ingrosso ottimale. Analizzare il valore che l'API genererà per il cliente in ogni fase del percorso.
Valutare la possibilità di applicare una strategia di determinazione dei prezzi basata su valori se il valore diretto dell'API al cliente è ben compreso.
Calcolare i livelli di utilizzo previsti dell'API per un cliente e il numero previsto di clienti per tutta la durata dell'API.
Passaggio 2: Quantificare i costi
Calcolare il costo totale di proprietà per l'API.
Costo | Descrizione |
---|---|
Costo dell'acquisizione del cliente (COCA) | Costo del marketing, delle vendite e dell'onboarding. Le API più efficaci tendono ad avere una COCA con zero man mano che aumentano i livelli di adozione. Le API devono essere in gran parte self-service nell'onboarding. I fattori includono la documentazione e l'integrazione senza attriti con i sistemi di pagamento. |
Costi di progettazione | Le risorse umane necessarie per compilare, testare, gestire e gestire l'API per tutta la durata. Tende a essere il componente di costo più significativo. Se possibile, sfruttare le tecnologie PaaS cloud e serverless per ridurre al minimo. |
Costi dell'infrastruttura | I costi per le piattaforme sottostanti, il calcolo, la rete e l'archiviazione necessari per supportare l'API per tutta la durata. Sfruttare le piattaforme cloud per ottenere un modello di costo dell'infrastruttura che aumenta proporzionalmente in linea con i livelli di utilizzo delle API. |
Passaggio 3: Condurre ricerche di mercato
- Ricercare il mercato per identificare i concorrenti.
- Analizzare le strategie di monetizzazione dei concorrenti.
- Comprendere le funzionalità specifiche (funzionali e non funzionali) offerte con l'API.
Passaggio 4: Progettare il modello di ricavi
Progettare un modello di ricavi in base al risultato dei passaggi precedenti. È possibile lavorare su due dimensioni:
Dimensione | Descrizione |
---|---|
Qualità del servizio | Impostare vincoli sul livello di servizio offerto impostando un limite per l'utilizzo dell'API. Definire una quota per le chiamate API che possono essere effettuate in un periodo di tempo (ad esempio, 50.000 chiamate al mese) e quindi bloccare le chiamate una volta raggiunta la quota. È anche possibile impostare un limite di velocità, limitando il numero di chiamate che possono essere effettuate in un breve periodo (ad esempio, 100 chiamate al secondo). I limiti limite e velocità vengono applicati in combinazione, impedendo agli utenti di consumare la quota mensile in un breve burst intensivo di chiamate API. |
Price | Definire il prezzo unitario da pagare per ogni chiamata API. |
Ottimizzare il valore di durata (LTV) generato da ogni cliente progettando un modello di ricavi che supporta il cliente in ogni fase del percorso del cliente.
- Rendere più semplice possibile la scalabilità e la crescita dei clienti:
- Suggerire ai clienti di passare al livello successivo nel modello di ricavi.
- Ad esempio, premiare i clienti che acquistano un volume maggiore di chiamate API con un prezzo unitario inferiore.
- Mantenere il modello di ricavi il più semplice possibile:
- Bilanciare la necessità di fornire una scelta con il rischio di sovraccaricare i clienti con una serie di opzioni.
- Mantenere il numero di dimensioni usate per distinguere i livelli del modello di ricavi.
- Essere trasparenti:
- Fornire una documentazione chiara sulle diverse opzioni.
- Offrire ai clienti strumenti per scegliere il modello di ricavi più adatto alle proprie esigenze.
Identificare l'intervallo di modelli di determinazione prezzi necessari. Un modello di determinazione prezzi descrive un set specifico di regole per il provider di API per trasformare l'utilizzo da parte del consumer dell'API in ricavi.
Ad esempio, per supportare le fasi precedenti del cliente, sono necessari sei tipi di sottoscrizione:
Tipo di sottoscrizione | Descrizione |
---|---|
Free |
Consente al consumer dell'API di eseguire la valutazione dell'API in modo obbligatorio e gratuito per determinare se soddisfa un caso d'uso. Rimuove tutte le barriere all'ingresso. |
Freemium |
Consente al consumer dell'API di usare gratuitamente l'API, ma di passare a un servizio a pagamento man mano che aumenta la domanda. |
Metered |
Il consumer dell'API può effettuare tutte le chiamate desiderate al mese e pagherà un importo fisso per ogni chiamata. |
Tier |
Il consumer dell'API paga per un numero impostato di chiamate al mese. Se superano questo limite, pagano un importo di eccedenza per ogni chiamata aggiuntiva. Se si verificano regolarmente eccedenze, possono eseguire l'aggiornamento al livello successivo. |
Tier + Overage |
Il consumer dell'API paga per un numero impostato di chiamate al mese. Se superano questo limite, pagano un importo impostato per ogni chiamata aggiuntiva. |
Unit |
Il consumer dell'API paga per un importo di chiamata impostato al mese. Se superano questo limite, devono pagare per un'altra unità di chiamate. |
Il modello di ricavi definirà il set di prodotti API. Ogni prodotto API implementa un modello tariffario specifico per definire una fase specifica nel ciclo di vita del consumer dell'API.
Anche se i modelli tariffari in genere non devono cambiare, potrebbe essere necessario adattare la configurazione e l'applicazione dei modelli di determinazione prezzi per il modello di ricavi. Ad esempio, è possibile modificare i prezzi in modo che corrispondano a un concorrente.
Basandosi sugli esempi precedenti, è possibile applicare i modelli di determinazione dei prezzi per creare un modello di ricavi complessivo come indicato di seguito:
Fase del ciclo di vita del cliente | Modello di determinazione prezzi | Configurazione del modello tariffario | QoS (Quality of Service) |
---|---|---|---|
Analisi | Disponibile | Non implementata. | Quota impostata per limitare il consumer a 100 chiamate al mese. |
Implementazione | Freemium | Livelli laureati:
|
Nessuna quota impostata. L'utente può continuare a effettuare e pagare le chiamate con un limite di frequenza di 100 chiamate al minuto. |
Anteprima | Misurato | Prezzo impostato per addebitare al consumatore $ 0,15/100 chiamate. | Nessuna quota impostata. L'utente può continuare a effettuare e pagare le chiamate a un limite di 200 chiamate al minuto. |
Utilizzo iniziale della produzione | Livello | Prezzo impostato per addebitare al consumatore $ 14,95 al mese. | Quota impostata per limitare il consumer a 50.000 chiamate al mese con un limite di frequenza di 100 chiamate al minuto. |
Crescita iniziale | Livello e eccedenza | Livelli laureati:
|
Nessuna quota impostata. Il consumatore può continuare a effettuare e pagare per chiamate aggiuntive a un limite di 100 chiamate al minuto. |
Ridimensiona | Livello e eccedenza | Livelli laureati:
|
Nessuna quota impostata. L'utente può continuare a effettuare e pagare per chiamate aggiuntive a un limite di 1.200 chiamate al minuto. |
Crescita globale | Unità | Livelli laureati, in cui ogni importo piano di livello è $ 749,95 al mese per 1.500.000 chiamate. | Nessuna quota impostata. Il consumatore può continuare a effettuare e pagare per chiamate aggiuntive a un limite di 3.500 chiamate al minuto. |
Due esempi di come interpretare il modello di ricavi in base alla tabella precedente:
Modello tariffario del piano
Applicato per supportare i consumer di API durante la fase di produzione iniziale del ciclo di vita. Con la configurazione del modello di determinazione prezzi del piano, il consumer:- Paga $ 14,95 al mese.
- Può effettuare fino a un massimo di 50.000 chiamate al mese.
- Frequenza limitata a 100 chiamate al minuto.
Fase di scalabilità del ciclo di vita Implementata applicando il modello tariffario Tier + Overage , in cui i consumer:
- Pagare $ 449,95 al mese per le prime 500.000 chiamate.
- Vengono addebitati 0,06$/100 chiamate aggiuntive oltre i primi 50.000 dollari.
- Frequenza limitata a 1.200 chiamate al minuto.
Passaggio 5: Calibrare
Calibrare i prezzi nel modello di ricavi per:
- Impostare i prezzi per evitare l'overpricing o la sottoprecing dell'API, in base alla ricerca di mercato nel passaggio 3 precedente.
- Evitare punti nel modello di ricavi che sembrano ingiusti o incoraggiano i clienti a aggirare il modello per ottenere prezzi più favorevoli.
- Assicurarsi che il modello di ricavi sia destinato a generare un valore di durata totale (TLV) sufficiente per coprire il costo totale di proprietà più margine.
- Verificare che la qualità delle offerte di servizio in ogni livello del modello di ricavi possa essere supportata dalla soluzione.
- Ad esempio, se si offre di supportare 3.500 chiamate al minuto, assicurarsi che la soluzione end-to-end possa essere ridimensionata per supportare tale livello di velocità effettiva.
Passaggio 6: Rilasciare e monitorare
Scegliere una soluzione appropriata per raccogliere i pagamenti per l'utilizzo delle API. I provider tendono a rientrare in due gruppi:
Piattaforme di pagamento, ad esempio Stripe
Calcolare il pagamento in base alle metriche di utilizzo dell'API non elaborate applicando il modello di ricavi specifico scelto dal cliente. Configurare la piattaforma di pagamento per riflettere la strategia di monetizzazione.
Fornitori di pagamenti, come Adyen
Solo per quanto riguarda l'facilitazione della transazione di pagamento. È necessario applicare la strategia di monetizzazione (ad esempio, convertire le metriche di utilizzo dell'API in un pagamento) prima di chiamare questo servizio.
Usare Azure Gestione API per accelerare e de-rischiare l'implementazione usando le funzionalità predefinite fornite in Gestione API. Per altre informazioni sulle funzionalità specifiche di Gestione API, vedere come Gestione API supporta la monetizzazione.
Implementare una soluzione che crei flessibilità nel modo in cui codifica la strategia di monetizzazione nei sistemi sottostanti usando lo stesso approccio del progetto di esempio. Con la codifica flessibile, è possibile rispondere in modo dinamico e ridurre al minimo il rischio e il costo di apportare modifiche.
Seguire la documentazione relativa alla monetizzazione del repository GitHub per implementare il progetto di esempio nella propria sottoscrizione di Azure.
Monitorare regolarmente il modo in cui viene usata l'API per consentire di prendere decisioni basate sulle prove. Ad esempio, se l'evidenza mostra che si stanno variando i clienti, ripetere i passaggi da 1 a 5 precedenti per individuare e risolvere l'origine.
Evoluzione in corso
Rivedere regolarmente la strategia di monetizzazione rivedendo e rivalutando tutti i passaggi precedenti. Potrebbe essere necessario evolvere la strategia di monetizzazione nel tempo man mano che si apprendono maggiori informazioni sui clienti, sui costi per fornire l'API e su come rispondere al cambiamento della concorrenza nel mercato.
Tenere presente che la strategia di monetizzazione è solo un facet di un'implementazione dell'API riuscita. Altri facet includono:
- Esperienza di sviluppo
- Qualità della documentazione
- Termini legali
- Possibilità di ridimensionare l'API per soddisfare i livelli di servizio di cui è stato eseguito il commit.
Passaggi successivi
- Come Gestione API supporta la monetizzazione.
- Distribuire un'integrazione demo di Adyen o Stripe tramite il repository Git associato.