How to Build a Personalized Developer Experience to Onboard Developers Faster

Updated:
8 minute read

Given the success of Box, Atlassian, and Salesforce, companies are launching new developer platforms at an unprecedented rate to position themselves as market leaders and expand their reach beyond their core product offerings. These companies have thousands of third party developers hooking into their APIs to extend product functionality and create additional revenue channels for both the platform company and the third party developers.

However, in order to attract and retain these developers, much thought must be put into the developer onboarding. It should be as seamless as possible for the junior developer yet surface advanced functionality at key moments for the valuable evangelists.

Key issues running a developer platforms

Onboarding Churn

TTFHW (Time To First Hello World) is the single most important metric to measure the success of a developer platform. TTFHW is the time it takes from an initial sign up to the first API transaction made on an API that creates value. TTFHW, is the developer version of time to first value.

Because developers are known for having a limited attention span for products that don’t fulfill their need, platform companies should invest heavily in reducing this metric as much as possible. If a developer doesn’t get or see value integrating a new API, they will never deploy that app to production and eventually churn.

Underutilized Functionality

Even when a developer made his or her first API call, the platform may not be fully utilized. Large APIs can have hundreds or thousands of different features and endpoints, but developers may only get started with a select few features. It’s up to platform companies to show off additional features and functionality that can drive additional value for both parties.

Poor Developer Experience

Your experience should enable a new developer to find information quickly without contacting support. In addition, when a developer is blocked, he or she should have access to the necessary information to get unblocked as fast as possible. It is critical to track which design issues with your API and onboarding experience cause the most frustration.

Why a personalized experience?

A personalized onboarding and product experience driven by actual usage data can cause new developers to integrate faster, resolve blockers more quickly, and retain them as successful partners. A personalized experience can achieve three goals:

1. Onboard developers faster

Instead of overloading developers with many integration options and actions in a single onboarding step, you can gradually onboard developers gradually as they use your platform over the coming days or weeks. If you haven’t already, brainstorm on what is the minimum integration required that demonstrates value to the newly acquired developer. In addition, map out a decision tree on the various paths a developer can follow to successfully complete the onboarding.

Your third party developers don’t need to integrate all the features or even have an integration that’s suitable for production or high traffic volume. However, once a developer has finished that first step, you can detect that, and then surface the next actions a developer should take. This requires a system that can track the progress of each developer in your onboarding funnel.

2. Effectively communicate relevant changes and features

If there are two thing all developers hate, they are:

  1. Too little or irrelevant communication
  2. Waking up to find their code broken by a third party that decided to change or deprecate an API

Thus, you need to communicate changes to your platform while ensuring your communication is on point and relevant. Developers are bombarded with hundreds of emails a day from recruiters to production alerts and ticketing systems. Your monthly newsletter will not be sufficient to communicate changes, yet increasing newsletter frequency will only make things worse.

Personalized in-app communication is an effective way to reach the right audience at the right time. With personalized communication, you should be doing the following:

  1. When a specific version of an endpoint will sunset, surface notifications to the developers who are using the deprecated version specifying how many calls are being made to the deprecated endpoint. You should also include a link to a migration plan tailored for their existing version.
  2. When additional functionality is added, such as additional filtering and data manipulation to an endpoint they’re already using, let them know the functionality exists and how to take advantage of it.
  3. When an endpoint is having performance issues such as latency spikes, let the impacted developers know of the ongoing issue and any updates on resolution. Of course, you shouldn’t spam your entre developer community when they may not even be impacted by the issue.
  4. Inform developers when their implementation can be improved for tighter security, higher performance, or other changes since they are using an outdated SDK or integration.
  5. Provide additional feedback and tips to developers who were not able to move forward to the next step in your onboarding funnel. This can be done via in-app guides, tool tips, and targeted drip emails.

3. Analyze successful developer cohorts

Once your platform has been live for a few months, you have some data to perform developer cohort analysis and see how your developer retention changes over time. Is your retention curve getting better as your developer experience improves? Because APIs are consumed by a variety of different environments, programming languages, and business use cases, it’s important to break your cohorts down by additional traits such as SDK used. For example, by breaking down your weekly or monthly retention by the SDK or language used, you can identify if there are specific SDKs that may need some improvement in reliability, ease of integration, or additional documentation. You should strive for your retention curves to not vary across developer traits like programming language, country, or cloud provider used.

In addition, you should overlay API changes and issues that arise on these cohorts. Did a recent outage impact developer retention drastically?

Finally, if you’re A/B testing your onboarding experience, you should be comparing your developer cohorts based on the onboarding variant or the first API call. Do developers with a very small TTFHW stick around longer?

How to build a personalized developer experience

In today’s environment with hundreds or thousands of developer platforms and SaaS companies, it’s critical for you to spend effort optimizing your middle of the funnel, which includes developer onboarding. One of the common mistakes new product managers make is to over-optimize acquisition and growth without considering how a leaky boat severely impacts your business’s bottom line. Yet, creating personalized experiences requires the right set of data and services.

If the core competency of your business is not product analytics, you explore best-of-breed solutions that enable personalized onboarding and in-app experience. Analytics leaders Moesif and Pendo are working together to provide a complete solution for product teams to build personalized developer experiences without needing to build costly, one-off solutions that do not scale.

What is Moesif? Moesif is the most advanced API analytics platform used by over 2000 organizations to understand what your most loyal customers are doing with your APIs, how they’re accessing them, and from where.

Why we partnered with Pendo?

We’re excited to partner with Pendo to bring this developer centric experience to life. Pendo provides customers with a product experience platform that increases product adoption, centralize user feedback, and enables product teams to measure and improve their product experience. From the very first discussion, Pendo and Moesif realized our visions are aligned with in that company need to treat their APIs as a product by itself in order to unlock additional growth and is a market leader in the product experience space.

The integration will combine the best of both tools and enable data-driven product teams with more ways to analyze and communicate with their developers based on usage data rather than gut feeling. “The integration between Moesif and Pendo gives API-driven businesses the best of both platforms”, said Chad Burnette, Pendo’s Head of Platform. “This is a problem I have spent countless engineering resources working to solve in the past. Now the market has an easy and scalable way to instrument APIs and then use that data to message developers directly to ease onboarding and drive greater adoption. This is perfect as you build your developer community.”

The components

There are four core components that enable you to offer a personalized developer experience:

1. Collection of API Usage Data

You should have a system that can collect API usage data and attribute this to individual developer accounts. This attribution can be done through API keys, user ids, or other identifiable information. This can be done automatically via an API analytics SDK like Moesif. Key metrics you want to collect from your APIs include:

  • REST route or feature used
  • Version of API or endpoint used
  • How long the call took
  • The User-Agent or SDK used
  • Where it came from geographically

2. Collection of UI Interactions

In addition to collecting API data, you will also need usage data from your UI such as your web application. This can be done directly from your browser javascript code or can be done automatically via a web analytics SDK like Pendo. You should collect at least the following:

  • When a user signs up
  • The pages or steps in your onboarding flow.
  • The browser or device used
  • When a user exits onboarding

3. Analytics system to combine and segment this data

If you’re building an in-house system, you’ll need a way to combine your web history with your API history for each developer. This way you can perform more advanced segmentation and cohort analysis on your third party community. Specific features you’ll need in this analytics service:

  • Ability to split developers into cohorts and perform retention analysis
  • A way to filter or group by past actions on an API or website
  • Sync user attributes from a CRM or user database which include information like revenue or LTV
  • Import attribution information such as UTM parameters for referrals and digital marketing.

4. UI elements to enable in-app messaging and notifications

Once you have a system that can collect and analyze this data, you’ll need to create various UI elements such as banners, popup modals, and notifications that can be driven from this user data. Critical to this is driving it at the right time while also providing flexibility in A/B testing this messaging. By A/B testing, you can measure the effectiveness of each onboarding flow and improve.

Closing thoughts

Creating amazing good developer experiences requires treating your platform as a product. This means you need to track, measure, analyze, test, and repeat. Once you are able to follow this process, you’ll have the tools to improve your API retention and drive higher API adoption.

Leave a comment