Regardless of whether you are monetizing your APIs, the effectiveness of your developer onboarding is a critical task that you cannot ignore. A good way to assess whether this is a problem is to review the data from a few key points in your activation funnel for new developers.
Below are several key stages in your developer onboarding funnel to ensure you are tracking.
- Time the developer first visits your developer portal
- Time the developer registers for an account in the developer portal
- Time an API key is requested, if this does not occur automatically with the first step
- While some developer portals automatically grant you access to your API keys as soon as you register, I recommend separating these events and tracking them separately as this gives you a more granular idea of where you may have gaps in your onboarding funnel.
- Also, more generally, you’ll want your developer portal to support granting multiple keys if required by your users and to rotate them if required, so not automatically granting keys upon registration provides multiple benefits.
- Time of first successful API call
- Time of first failed API call
- Time of first production integration
- This could be done based on you granting a first key for development and a separate key for production (Stripe is a well-known provider that separates their API credentials this way.
- If not providing separate credentials for staging and production, this may be a datapoint you have to infer, and if so, generally it can be done based on volume. Initially you will note a small number of infrequent transactions changing to higher numbers with relative regularity that indicates a move from development to production.
- Choose the business rules that apply to you and do your best to capture this date.
In addition to the steps above, if you are using marketing engagement software to do outreach en masse, you may have access to one additional data point related to the time the developer was first added to your funnel. If you have access to this data, it is valuable to include it in your tracking as it will help to assess the effectiveness of your outbound marketing in converting cold leads to potential customers.
If you aren’t tracking all of the data points above, you’re certainly not alone, and if you don’t have the data today, we strongly recommend you put a plan in place to start capturing as much of the information as possible.
Next, let's review the movement between stages and how you can improve conversion rates at each gate.
From First Dev Portal Visit to Registration
If your conversion rates at this stage are low or lag times are long between stages, there are two possible culprits to review:
One: Evaluate the profiles your marketing team is using to drive customers to your portal. If the marketing funnel is set up properly, they should be able to evaluate conversion rates at this stage from various sources and determine if one or more marketing campaigns are sending the wrong types of customers to your portal that are not converting at high rates.
Two: If you’re confident that the target audience is correct, and you’re still failing to convert to registered users, you’re going to have to dig deeper.
‼️ Remember, developers are much more likely to be focused on problems rather than features, and the information on your landing page should be as well.
Ensure that your marketing pages are very clear on the problems the APIs solve and are not overflowing with features and extraneous information. This is rarely the correct approach with developers.
From Registered User to API Key Request
For this stage, put yourself in the developer’s shoes. You’ve just taken the time to register for a portal even knowing that you’ll receive unsolicited marketing emails as a result. So either you’ve got time to kill (rare), or you have a real problem to solve and you’re ready to solve it.
In a properly designed site, the time to advance from site registration to API key request should be low, and the conversion rates should be high. It is important that your call to action at this stage is very clear. As an example, if the first required step is for a developer to confirm their email address, the landing page they hit after doing so should clearly tell them what they should do “to get to solving problems”, not tell them to close the window and return to the main page.
If your development portal provides keys that access all APIs, don’t make the process to create a key hard to find, link directly to it. If on the other hand your development portal offers access to several products with individual keys granted for each, it is best to present the developer with a list of the most common use cases (problems) you help solve, and provide direct links to the page to request API keys for each of those products.
If adoption at this stage is low, ensure you have a good automated email drip campaign that reminds developers of the top problems your API solves, and has a clear call-to-action in every email that tells them how to get their API keys.
From API Key Creation to "Hello World"
(or to first erroneous call made with valid credentials)
At the risk of stating the obvious, this is a particularly critical step in API adoption, and probably the hardest one to optimize of those we’ve reviewed.
To clear this gate, the developer must have successfully received their API credentials, reviewed your API documentation, constructed code to access the API, and received a successful response. In other words, a lot has to go right to get through this step, and a failure at any one of the previous stages will prevent the developer from passing this point.
So… what are the top things you can do in this stage to ensure success? Obviously, up-to-date and thorough documentation is critical here, and best practices in this area are a topic in and of themselves, so we will keep the recommendations high level.
- Provide sample code snippets and sample API responses, and make them very easy to understand and consume.
- curl commands are the easiest to understand and the hardest to screw up. Make it obvious where credentials must be inserted, and where other variables are required, include actual examples with variables that will result in a successful call for someone who does not understand your API.
- Publish Postman collections. Most developers regularly work in this environment, and providing a ready-to-go collection will provide an easy on-ramp to using your APIs. Ensure that you provide comments in your collections at any likely points of confusion to minimize user drop off at this step.
- For code snippets you provide in other languages, find a developer in your company or network who does not work with your API, give them a link to the sample code, give them credentials, and observe how long it takes them to make their first successful call. (the result should be measured in seconds or in a very small number of minutes. If you fail that test, your examples aren’t good enough)
- Although this probably sounds obvious, even as seasoned API practitioners, we sometimes follow the documentation provided by our clients and attempt to access their API using code samples in their development portal and find it to be incredibly challenging.
In addition to code snippets, the following are all additional ways to help developers successfully adopt your API:
- Utilize interactive tutorials that prompt the user for input and output finished code. This can sometimes be more effective than documentation alone.
- Offer short pre-recorded videos explaining how to integrate in different coding languages.
- If you have a high volume of new developers every week, consider a standing once/week technical session led by an engineer who can answer questions in real time via web conference with live chat enabled.
- Developer forums are another method to improve adoption, but this is not a trivial choice as these can be high cost/effort to properly support, so do not make this decision lightly.
The subheading of this section mentions not only tracking time to first success but also time to failure. For new users of the API, it is important to identify the calls they send and why they fail. This is a great place to look for patterns of malformed requests so that you can update your documentation and FAQs to help future developers navigate around common problems.
Similar to the last stage, if adopting at this stage is low, ensure you implement an automated email campaign aimed at helping developers integrate for the first time. These messages should be tailored to demonstrate how easy it is to successfully call the API in various languages. Also ensure that every email explains how to access the credentials they previously created, and highlight whatever API adoption resources you decide to make available from the list of recommendations above.
From successful call to production usage:
If you are converting large numbers of developers to reach this gate in your funnel, you’re doing very well. Unfortunately, if you don’t get them past this last hurdle, all of the previous work was for naught. So, let’s first review the possible outcomes and then identify the most common things that can cause a failure to advance beyond this gate.
It is important to remember that at the previous stage, the developer was verifying the simple ability to send a request and receive an expected response. To move from that stage to production, the developer may need only to plug a few lines of code into an existing application with large usage volumes to replace an existing function, at which point you’ll see a giant jump in usage and know you’re successfully integrated.
Conversely, though, the developer may be creating their application from the ground up and utilizing your API for a portion of its functionality only once it goes live. This process for the partner to launch their own product could take months, and nothing you do could make the process go any faster.
The challenge for the API producer in the latter scenario is that you don’t know if it is product deficiency on your side causing the delays or if there is anything you can do to help. This is where a strong developer relations or client success team (depending on your organization’s structure) comes in.
If the API you are productizing is sold from one enterprise to another, you may have the luxury of being able to reach out to the partner development team at this point to understand the expected timelines and ensure there are open communication lines if anything goes wrong during the integration.
If, however, you are selling largely in a self-service model, then automating your developer check-ins may be more realistic. For example, you should develop an automated routine that alerts you and potentially emails developers whose usage stops or drops off dramatically.
Notwithstanding the guidance above, avoid completely automating developer communications in the early stages, as the learnings from a personal engagement in the early days of product development are often invaluable in learning what is blocking production adoption.
Also, this is the stage in the process where the potential obstacles are the most variable, so allocating a team to be responsible for direct customer support at this stage will often provide the best ROI as it is the hardest to automate success at this stage of the funnel. Establishing Discord and Slack-based support channels for this team to monitor effectively creates direct engagement between external developers and your own technical teams, who can help with onboarding.
In closing, moving a developer from product awareness to product adoption is a long journey with many potential pitfalls. When you are launching a new API product, it is important to be able to produce analytics at each stage of the journey so that you know where to focus your efforts on improving adoption.
