Bevételszerzés az Azure API Managementtel
A KÖVETKEZŐRE VONATKOZIK: Minden API Management-szint
A modern webes API-k támogatják a digitális gazdaságot. A vállalat szellemi tulajdonát (IP-címét) harmadik feleknek nyújtják, és bevételt termelnek a következők révén:
- Ip-cím csomagolása adatok, algoritmusok vagy folyamatok formájában.
- Lehetővé teszi, hogy más felek egységes, súrlódásmentes módon deríthessék fel és használják fel a hasznos IP-címeket.
- Ennek a használatnak a közvetlen vagy közvetett fizetésére szolgáló mechanizmust kínál.
Az API-sikertörténetek gyakori témája egy egészséges üzleti modell. Az érték az összes fél között fenntartható módon jön létre és cserélhető le.
Az induló vállalkozások, a létrehozott szervezetek és a közöttünk lévő összes jellemzően az üzleti modelltől kezdve a digitális átalakításra törekszenek. Az API-k lehetővé teszik az üzleti modell megvalósulását, ami egyszerűbb és költséghatékonyabb módot tesz lehetővé a marketinghez, a mögöttes IP bevezetéséhez, felhasználásához és skálázásához.
Az első API-t közzétevő szervezetek összetett döntési csoporttal szembesülnek. Bár az Azure API Management platform eszkalálja a kockázatokat, és felgyorsítja a kulcsfontosságú elemeket, a szervezeteknek továbbra is konfigurálniuk kell és létre kell készíteniük az API-t az egyedi műszaki és üzleti modelljük köré.
Bevételszerzési stratégia kidolgozása
A bevételszerzés a pénzzé alakítás folyamata – ebben az esetben az API-érték. Az API-interakciók általában három különböző felet foglalnak magukban az értékláncban:
Az API-bevételszerzési stratégia kategóriái a következők:
| API-bevételezési stratégia | Leírás |
|---|---|
| Ingyenes | Az API-k megkönnyítik az üzleti integrációt, például egy ellátási lánc rastreamelését. Az API nem bevételszerzés, hanem jelentős értéket biztosít azáltal, hogy az üzleti folyamatok hatékonyságát mind az API-szolgáltató, mind az API-fogyasztó számára lehetővé teszi. |
| Fogyasztói fizetések | Az API-felhasználók az API-val folytatott interakciók száma alapján fizetnek. Ebben a dokumentumban erre a megközelítésre összpontosítunk. |
| A fogyasztó fizetése | Egy API-felhasználó például az API használatával ágyazza be a hirdetéseket a webhelyére, és megkapja a létrehozott bevétel egy részét. |
| Közvetett bevételszerzés | Az API-bevételszerzést nem az API-val való interakciók száma vezérli, hanem az API által támogatott egyéb bevételi forrásokon keresztül. |
Feljegyzés
A bevételszerzési stratégiát az API-szolgáltató állítja be, és úgy kell megtervezni, hogy megfeleljen az API-fogyasztó igényeinek.
Mivel számos tényező befolyásolja a kialakítást, az API-bevételszerzés nem egy méretre illeszkedő megoldás. A bevételszerzési stratégia megkülönbözteti az API-t a versenytársaktól, és maximalizálja a létrehozott bevételt.
Az alábbi lépések bemutatják, hogyan implementálhat bevételszerzési stratégiát az API-hoz.
1. lépés: Az ügyfél megismerése
Az API-felhasználók valószínűsíthető folyamatának szakaszainak feltérképezése az API első felfedezésétől a maximális skálázásig.
Az ügyfélszakaszok például a következők lehetnek:
Ügyfélszakasz Leírás Vizsgálat Engedélyezze az API-fogyasztónak, hogy nulla költséggel és súrlódással próbálja ki az API-t. Implementálás Biztosítson elegendő hozzáférést az API-hoz, hogy támogassa az integrációhoz szükséges fejlesztési és tesztelési munkát. Előzetes verzió Lehetővé teszi az ügyfél számára, hogy elindítsa ajánlatát, és megértse a kezdeti igényeket. Kezdeti éles használat Támogatja az API korai bevezetését az éles környezetben, ha a használati szintek nem teljesen ismertek, és szükség lehet kockázat-kedvezőtlen megközelítésre. Kezdeti növekedés Engedélyezze az API-fogyasztónak, hogy növelhesse az API használatát a végfelhasználók megnövekedett igényeire válaszul. Hangsor Ösztönözze az API-fogyasztót arra, hogy nagyobb mennyiségű vásárlásra kötelezze el magát, ha az API folyamatosan magas szintű használatot ér el minden hónapban. Globális növekedés Az API-t globális szinten használó API-felhasználók jutalmazása az optimális nagykereskedelmi ár felajánlásával. Elemezze azt az értéket, amelyet az API generál az ügyfél számára a folyamat minden szakaszában.
Érdemes lehet értékalapú díjszabási stratégiát alkalmazni, ha az API közvetlen értéke jól érthető az ügyfél számára.
Számítsa ki az API várható élettartam-használati szintjeinek értékét egy ügyfél esetében, valamint az api élettartama során várható ügyfelek számát.
2. lépés: A költségek számszerűsítése
Számítsa ki az API tulajdonjogának teljes költségét.
| Költség | Leírás |
|---|---|
| Ügyfélszerzés költsége (COCA) | A marketing, az értékesítés és az előkészítés költsége. A legsikeresebb API-k általában nulla COCA-val rendelkeznek a bevezetési szintek növekedésével. Az API-knak nagyrészt önkiszolgálónak kell lenniük az előkészítés során. A tényezők közé tartozik a dokumentáció és a fizetési rendszerekkel való súrlódásmentes integráció. |
| Mérnöki költségek | Az API létrehozásához, teszteléséhez, működtetéséhez és karbantartásához szükséges emberi erőforrások az élettartamuk során. Ez általában a legjelentősebb költségösszetevő. Ahol lehetséges, használja ki a felhőbeli PaaS-t és a kiszolgáló nélküli technológiákat a minimálisra csökkentése érdekében. |
| Infrastrukturális költségek | Az API támogatásához szükséges mögöttes platformok, számítási, hálózati és tárolási költségek. A felhőplatformokat kihasználva olyan infrastruktúraköltség-modellt érhet el, amely az API használati szintjeinek megfelelően arányosan felskálázható. |
3. lépés: Piackutatás végzése
- A piac kutatása a versenytársak azonosítására.
- A versenytársak bevételszerzési stratégiáinak elemzése.
- Megismerheti az API-val kínált konkrét (funkcionális és nem funkcionális) funkciókat.
4. lépés: A bevételi modell tervezése
A fenti lépések eredményei alapján tervezzen meg egy bevételi modellt. Két dimenzióban dolgozhat:
| Dimenzió | Leírás |
|---|---|
| A szolgáltatás minősége | Az API-használat korlátjának beállításával korlátozza a kínált szolgáltatásszintet. Definiáljon egy kvótát az api-hívásokhoz, amelyek egy adott időszakban (például havonta 50 000 hívás) indíthatók, majd tiltsa le a hívásokat a kvóta elérése után. Beállíthat egy sebességkorlátot is, amely szabályozza a rövid időn belül indítható hívások számát (például másodpercenként 100 hívást). A korlátokat és a sebességkorlátokat együtt alkalmazza a rendszer, így a felhasználók nem tudják használni a havi kvótájukat az API-hívások rövid, intenzív sorozatában. |
| Ár | Határozza meg az egyes API-hívásokért fizetendő egységárat. |
Maximalizálja az egyes ügyfelek által generált élettartam-értéket (LTV) egy olyan bevételi modell kialakításával, amely támogatja az ügyfelet az ügyfélút minden szakaszában.
- Tegye a lehető legegyszerűbbé az ügyfelek számára a méretezést és a növekedést:
- Javasolja az ügyfeleknek, hogy lépjenek a következő szintre a bevételi modellben.
- Jutalmazza például azokat az ügyfeleket, akik nagyobb mennyiségű API-hívást vásárolnak alacsonyabb egységáron.
- Tartsa a bevételi modellt a lehető legegyszerűbben:
- Egyensúlyba kell helyeznie a választás szükségességét azzal a kockázattal, hogy az ügyfelek túlterhelik a lehetőségeket.
- A bevételi modell szintjei közötti különbségtételhez használt dimenziók számának megtartása.
- Legyen transzparens:
- Adjon egyértelmű dokumentációt a különböző lehetőségekről.
- Biztosítson az ügyfeleknek eszközöket az igényeiknek leginkább megfelelő bevételi modell kiválasztásához.
Azonosítsa a szükséges tarifamodellek tartományát. A díjszabási modell egy meghatározott szabálykészletet ír le arra vonatkozóan, hogy az API-szolgáltató bevételré alakítsa az API-fogyasztó általi felhasználást.
A fenti ügyfélszakaszok támogatásához például hat előfizetéstípusra lenne szükség:
| Előfizetés típusa | Leírás |
|---|---|
Free |
Lehetővé teszi az API-fogyasztó számára, hogy kötelezettség és költségmentes módon kipróbálja az API-t, hogy megállapítsa, megfelel-e a használati esetnek. Eltávolítja a belépési korlátokat. |
Freemium |
Lehetővé teszi, hogy az API-fogyasztó ingyenesen használja az API-t, de a kereslet növekedésével váltson fizetős szolgáltatássá. |
Metered |
Az API-fogyasztó havonta annyi hívást kezdeményezhet, amennyit csak szeretne, és hívásonként fix összeget fizet. |
Tier |
Az API-felhasználó havonta meghatározott számú hívásért fizet. Ha túllépik ezt a korlátot, többlethívásonként túlhasználatot fizetnek. Ha rendszeresen túlhasználatot váltanak ki, a következő szintre frissíthetnek. |
Tier + Overage |
Az API-felhasználó havonta meghatározott számú hívásért fizet. Ha túllépik ezt a korlátot, külön hívásonként meghatározott összeget fizetnek. |
Unit |
Az API-felhasználó havonta meghatározott mennyiségű hívást fizet. Ha túllépik ezt a korlátot, egy másik hívásegységért kell fizetniük. |
A bevételi modell határozza meg az API-termékek készletét. Minden API-termék egy adott díjszabási modellt implementál, amely az API fogyasztói életciklusának egy adott szakaszát célozza meg.
Bár a tarifamodellek általában nem változnak, előfordulhat, hogy módosítania kell a díjszabási modellek konfigurációját és alkalmazását a bevételi modellhez. Előfordulhat például, hogy az árakat úgy szeretné módosítani, hogy megfeleljen egy versenytársnak.
A fenti példák alapján a díjszabási modellek az alábbiak szerint hozhatók létre teljes bevételi modellként:
| Ügyfél életciklusának szakasza | Díjszabási modell | Díjszabási modell konfigurációja | A szolgáltatás minősége |
|---|---|---|---|
| Vizsgálat | Ingyenes | Nincs implementálva. | A fogyasztót 100 hívásra/hónapra korlátozó kvóta van beállítva. |
| Megvalósítás | Freemium | Diplomás szintek:
|
Nincsenek megadva kvóták. A fogyasztó továbbra is kezdeményezhet és fizethet a hívásokért 100 hívás/perc sebességkorláttal. |
| Előnézet | Forgalmi díjas | A fogyasztói 0,15 USD/100 hívások díjának beállítása. | Nincsenek megadva kvóták. A fogyasztó továbbra is kezdeményezhet és fizethet a hívásokért 200 hívás/perc sebességkorlátozás mellett. |
| Kezdeti éles használat | Szint | A fogyasztónak havi 14,95 usd díjat kell fizetnie. | A kvóta úgy van beállítva, hogy a fogyasztót 50 000 hívásra/hónapra korlátozza 100 hívás/perc sebességkorláttal. |
| Kezdeti növekedés | Réteg + Túlhasználat | Diplomás szintek:
|
Nincsenek megadva kvóták. A fogyasztó továbbra is kezdeményezhet és fizethet további hívásokat 100 hívás/perc sebességkorlát mellett. |
| Hangsor | Réteg + Túlhasználat | Diplomás szintek:
|
Nincsenek megadva kvóták. A fogyasztó továbbra is kezdeményezhet és fizethet további hívásokat 1200 hívás/perc sebességkorlát mellett. |
| Globális növekedés | Unit (Egység) | Diplomás szintek, ahol minden szint egyösszegű összege 749,95 USD/hó 1 500 000 hívás esetén. | Nincsenek megadva kvóták. A fogyasztó továbbra is kezdeményezhet és fizethet további hívásokat 3500 hívás/perc sebességkorlát mellett. |
Két példa arra, hogyan értelmezhető a bevételi modell a fenti táblázat alapján:
Réteg díjszabási modellje
Az API-fogyasztók támogatása az életciklus kezdeti éles fázisában alkalmazható. A tarifacsomag-modell konfigurációjával a fogyasztó:- Havi 14,95 dollárt fizet.
- Legfeljebb 50 000 hívást indíthat havonta.
- A sebesség legfeljebb 100 hívás/perc lehet.
Az életciklus skálázási fázisa a Tier + Overage díjszabási modell alkalmazásával implementálva, ahol a fogyasztók:
- Az első 500 000 hívásért havonta 449,95 dollárt kell fizetnie.
- Az első 50 000 hívás után további 0,06/100 usd díjat számítunk fel.
- Az arány 1200 hívás/perc.
5. lépés: Kalibrálás
A bevételi modell díjszabásának kalibrálása a következőre:
- Állítsa be a díjszabást az API túlárazásának vagy alulárazásának megelőzéséhez a fenti 3. lépésben ismertetett piackutatás alapján.
- Kerülje a bevételi modell azon pontjait, amelyek tisztességtelennek tűnnek, vagy arra ösztönzik az ügyfeleket, hogy a modell körül dolgozva kedvezőbb díjszabást érjenek el.
- Győződjön meg arról, hogy a bevételi modell olyan teljes élettartam-értéket (TLV) hoz létre, amely elegendő a teljes bekerülési költség és az árrés fedezéséhez.
- Ellenőrizze, hogy a megoldás támogatja-e az egyes bevételi modellszintek szolgáltatási ajánlatainak minőségét.
- Ha például 3500 hívást/percet támogat, győződjön meg arról, hogy a végpontok közötti megoldás skálázható az átviteli sebesség szintjének támogatására.
6. lépés: Kiadás és monitorozás
Válassza ki a megfelelő megoldást az API-k használatáért fizetendő fizetés beszedéséhez. A szolgáltatók általában két csoportba sorolhatók:
Fizetési platformok, például a Stripe
A nyers API-használati metrikák alapján számítsa ki a fizetést az ügyfél által választott adott bevételi modell alkalmazásával. Konfigurálja a fizetési platformot úgy, hogy tükrözze a bevételszerzési stratégiát.
Olyan fizetési szolgáltatók, mint az Adyen
Csak a fizetési tranzakció megkönnyítésével foglalkozik. A szolgáltatás meghívása előtt alkalmaznia kell a bevételszerzési stratégiát (például le kell fordítania az API használati metrikáit egy fizetésre).
Az Azure API Management használatával felgyorsíthatja és megszüntetheti az implementációt az API Management beépített képességeinek használatával. Az API Management egyes funkcióival kapcsolatos további információkért tekintse meg , hogyan támogatja az API Management a bevételszerzést.
Olyan megoldás implementálása, amely rugalmasságot épít be a bevételszerzési stratégia kodifikálásába a mögöttes rendszerekben a mintaprojekthez hasonló megközelítéssel. Rugalmas kódolással dinamikusan válaszolhat, és minimalizálhatja a módosítások kockázatát és költségét.
Kövesse a bevételszerzési GitHub-adattár dokumentációját a mintaprojekt saját Azure-előfizetésben való implementálásához.
Rendszeresen monitorozza, hogyan használja fel az API-t, hogy lehetővé tegye a bizonyítékokon alapuló döntések meghozatalát. Ha például a bizonyítékok azt mutatják, hogy ügyfeleket keres, ismételje meg a fenti 1–5. lépést a forrás feltárásához és kezeléséhez.
Folyamatban lévő fejlődés
A fenti lépések ismételt áttekintésével és újraértékelésével rendszeresen áttekintheti a bevételszerzési stratégiát. Előfordulhat, hogy idővel tovább kell fejlesztenie bevételszerzési stratégiáját, mivel többet tudhat meg az ügyfelekről, az API biztosításának költségeiről, valamint arról, hogy hogyan reagál a piaci verseny eltolódására.
Ne feledje, hogy a bevételszerzési stratégia csak egy aspektusa a sikeres API-implementációnak. Egyéb aspektusok a következők:
- A fejlesztői élmény
- A dokumentáció minősége
- A jogi feltételek
- Az API skálázható a lekötött szolgáltatási szinteknek megfelelően.
Következő lépések
- Hogyan támogatja az API Management a bevételszerzést?
- Demó Adyen- vagy Stripe-integráció üzembe helyezése a társított Git-adattáron keresztül.