Näin saat lisää API-käyttäjiä: 6 vinkkiä menestykseen

Autoin äskettäin yritystä, joka halusi parantaa kehittäjäkokemustaan. Heidän neljännesvuositavoitteenaan oli saada entistä enemmän uusia API-asiakkaita USA:n kotimarkkinoillaan.

Teimme API-auditoinnin heidän API kehittäjän kokemus. He tekevät tällä hetkellä kaikkia paksun tarkastusraporttini ehdottamia muutoksia, joten en mainitse nimeä. Mutta sanotaan näin, että he ovat alansa parhaita ja palvelevat suurimpia asiakkaita, kuten LinkedIn.

Heidän ja heidän kilpailijoidensa API-asiakaspolussa oli monia ongelmia, joista suurin osa oli hyvin tyypillisiä. Kaikkien tuotepäälliköiden ja kehittäjien hyödyksi halusin jakaa muutaman vinkin. Tehdään maailmasta parempi paikka API-käyttäjille.

Mutta ensin on pakko todeta se ilmeinen asia.

Arvo edellä, ei API edellä

Tärkein on ymmärtää ensin kuka on tai tulee olemaan API-käyttäjäsi. Mitä hyötyä he odottavat APiltasi.

Jos APIsi tarjoaa käyttäjille arvokasta palvelua tai tietoja, he todennäköisemmin käyttävät sitä. Ajattele tapoja, joilla voit API erottuuu kilpailijoista ja mieti potentiaalisia asiakastarpeita, joihin voit vastata ainutlaatuisella tarjonnalla. Kun olet tunnistanut, mitkä edut API tarjoaa, voit viestiä näistä eduista erilaisilla digitaalisilla alustoilla.

Mutta ennen kuin aiot tarjota APIa 3. osapuolen alustoille, sinun on tehtävä kotiläksyt omissa kanavissa ja rajapinnoissa.

Sivustosi ei saa olla kaunis

Pidä API dokumentaation tai API portaalin graafinen ilme linjassa brändisi kanssa, mutta silti vakuuttavana kehittäjillesi.

Potentiaalisten API-käyttäjien on löydettävä API. Jos suunnittelet kauniin sivuston erinomaisella grafiikalla, se ei silti välttämättä puhu kehittäjän sielulle. Kehittäjät haluavat sivustosi näyttävän hieman karkealta. On parasta, jos se on täynnä teknisiä yksityiskohtia. Pidä grafiikka kurissa, älä luo vaikutelmaa, että kehittäjän on ensin puhuttava myynnin kanssa!

Vertailin myös heidän kilpailijoidensa kehittäjäpolkuja osana API-auditointia. Sivuutimme muutaman ensimmäisen ehdokkaan, koska niissä piti puhua myynnin kanssa päästäkseen käsiksi APIin. Saatat tuntea houkutusta ajatella, että tämä oli hyvä asia. Kilpailijoiden ei pitäisi päästä sinun APIisi käsiksi liian nopeasti. Mutta huomioi, että lomakkeet, jotka minun piti täyttää, ja viestit, jotka sain, olivat suorastaan hämmentäviä. Joten kehittäjänä olisin joka tapauksessa juossut pois ja lujaa.

Onko APIsi piilotettu aarre?

API dokumentaation on oltava linkitetty pääsivustosi navigointiin.

Pysähdy hetkeksi. Katso pääbrändisi verkkosivustoa. Kuvittele, että olet potentiaalinen asiakas tai kumppani, joka ajattelee API on "ilahduttava" ominaisuus. He eivät ehkä etsi erityisesti APIa. He voivat olla projektipäälliköitä, tuotepäälliköitä, arkkitehtejä tai liiketoiminnasta vastaavia. Joten varmista, että API erottuu tuotepääsivuilta äläkä piilota sitä verkkosivustosi alareunan viimeiseksi linkiksi.

On myös monia muita tapoja löytää API, mutta tämä on helpoin asia korjata.

‍

Ole hyödyksi, älä haitaksi kehittäjille

Your API documentation usability starts from having clear descriptions of value. This means value propositions for each API. It is completed by having standard API designs with up-to-date useful working examples. 

• Kehittäjän on ymmärrettävä 3 sekunnissa, miksi tarjoat API Ja minkä ongelman se ratkaisee?
• 30 sekunnin pitäisi riittää kokeilemaan APIa ja tekemään ensimmäinen pyyntö
• Kehittäjän on voitava käyttää APIa 3 minuutissa omasta koodistaan

Tämä kuulostaa haastavalta, mutta olen tosissani. Jos kehittäjäkokemuksesi ja asiakaspolkusi eivät vastaa näitä tavoitteita, prospektisi siirtyvät seuraavaan APIin. Tai jos he ovat sisäisiä kehittäjiäsi tai palkattua apua, he ovat epämotivoituneita ja laskuttavat sinua enemmän. Ainoastaan jos APIsi tekee jotain uniikkia, tai yrityksesi on alansa paras, saatat pärjätä hitaammalla prosessilla. Mutta älä ole siitä liian varma.

Jotkut yritykset ovat ratkaisseet tämän tarjoamalla vain koodiesimerkkejä täyden API dokumentaation sijaan. Taustalla on selvästi oletus että hyppääminen prosessin viimeiseen vaiheeseen on tärkein. Suosittelen että et käytä oikopolkuja. Jos potentiaaliset API-käyttäjäsi eivät ymmärrä, miksi heidän pitäisi käyttää APIasi ei koodin tyrkyttäminen auta mitään.

E niin, etteikö koodiesimerkkien tai SDK:iden (ohjelmistokehityspaketit) tarjoaminen olisi hyvästä. Ehdottomasti, jos sinulla on resursseja ylläpitää niitä. Jos GitHubin koodikirjastossa lukee "päivitetty viimeksi neljä vuotta sitten", kehittäjäsi lukevat "hylätty" ja siirtyvät eteenpäin. Ei ole olemassa ohjelmointikieltä, joka ei tarvitsisi päivityksiä joka vuosi. Ja sinun APIasi on todennäköisesti päivitetty joka tapauksessa sillä välin. Joten millä todennäköisyydellä SDK:si toimisi enää?

Varmista, että on olemassa prosessi, jolla vastataan kysymyksiin ja ongelmiin, jotka tulevat kehittäjiltä, myös koodikirjastojen ja kehittäjäkanavien kautta. Ota myös huomioon, että kehittäjäsi eivät ehkä ole asiakaspalveluhenkisimpiä, etenkään, jos joku "kritisoi" heidän tuotostaan.

Roolit ja työkalut apuun

 API-tuotepäällikkö on välttämätön onnistuneelle API ohjelmalle. Jonkun on myös vastattava kehittäjäkokemuksesta ja suhteista.

Tähän mennessä luultavasti ajattelet, että tarjotaksesi APIn tarvitset vähintään armeijan kehittäjiä ja kehittäjäkokemuksen asiantuntijoita.

Et, mutta APIsi tarvitsee API-tuotepäällikön. Enkä tarkoita Scrumissa käytettyä tuoteomistajaa, vaan tuotepäällikköä, joka hoitaa APIn tuotteena asiakkaiden kanssa. Heidän tehtävänsä on selittää myynnille, markkinoinnille, asiakaspalvelulle ja kehittäjille, mitä ongelmia API ratkaisee. Miten se tuottaa arvoa asiakkaille?

Lisäksi API-tuotepäällikön tehtävä on valvoa, että kaikki dokumentaatio ja kehittäjän asiakaspolku toimivat. API-tuotepäällikön on työskenneltävä yhdessä kehittäjäsuhteista ja -yhteisöistä vastaavan henkilön kanssa. Heidän keskinäinen tehtävänsä on varmistaa, että yhteisöltäsi tulevat ongelmat ja ominaisuuspyynnöt priorisoidaan ja niihin vastataan.

Nopea korjaus tai täydellinen purkaminen?

Mitä sinun on tehtävä parantaaksesi API kehittäjäkokemusta riippuu olemassa olevien ohjelmointirajapintojen kunnosta ja API-dokumentaation tilasta. REST APIen olennainen lähtökohta on käyttää OpenAPI-määritelmiä. API-tuotepäällikkönä, sinun on edellytettävä tätä. Se auttaa APIn kehittäjiä automatisoimaan dokumentointiprosessit ja varmistamaan vakiokokemuksen. On olemassa työkaluja, jotka auttavat kehittäjiä tekemään tämän ja pakottavat käyttämään API-tyylioppaan sääntöjä.

Entä koodi, SDK:t ja dokumentaatio? Luo API käyttämällä OpenAPI-määritystä. Tai ainakin luo se koodista. Siten olet jo puolivälissä dokumentaation ja koodiesimerkkien laatimista. Varmista, että OpenAPI-dokumentaatiosi sisältää esimerkkejä pyynnöistä ja vastauksista. Tämän jälkeen voit käyttää API-hallinta-alustaa tai avoimen lähdekoodin työkalut. Työkalut voivat automaattisesti luoda dokumentaatiota ja koodiesimerkkejä eri kielillä. Tällä on myös pari muuta etua. API-käyttäjäsi voivat käyttää OpenAPI-määritelmää koodissaan ja automaattisessa testauksessaan. Voit käyttää OpenAPI-määritelmää myös APIn mockkaamiseen (= simulointiin), jopa ennen kuin yhtään koodia on kirjoitettu ja testiä luotu.

Lopuksi tärkeimmät

Aloitimme kysymyksellä siitä, miten saada enemmän API-käyttäjiä.

Helppo vastaus on, että sinun on markkinoitava APIasi, mitä käsitellään toisessa kirjotuksessa. 

Vaativampi vastaus on, että kehittäjien, jotka löytävät ja käyttävät APIasi, on oltava riittävän tyytäväisiä ryhtyäkseen maksaviksi asiakkaiksi tai arvokkaiksi kumppaneiksi. Sinun on siis työstettävä APIen kehittäjäkokemusta. Tarkista siis, nämä asiat kunnossa, tai laita ne työlistalle. 

1. Tutki ja vahvista APIen käyttäjäsegmenttien tarpeet ja suunnittele API-dokumentaatio ja APIt luomaan heille arvoa.
2. Tarkista API-dokumentaation tai API-portaalin graafinen suunnittelu ja sisältö. Varmista, että ne täyttävät brändin vaatimukset luodakseen luotettavan kuvan, sekä muut API-käyttäjien odotukset.
3. Tarkista, että APIt on helppo löytää brändisi verkkosivustolta ja muista markkinointi- ja myyntikanavista.
4. Luo ja vahvista API arvolupaukset ja tarkista, että ne näkyvät API-dokumentaatiossa.
5. Varmista, että sinulla on joku, joka vastaa API-tuotehallinnast ja kehittäjäsuhteista. Tämän henkilön tulisi olla sisäinen tai ainakin palkattu pitkällä sopimuksella.
6. APIt täyttävät tekniset standardit ja esimerkit.

‍