Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo medir el éxito de las relaciones con los desarrolladores

 ¿Cuál es su métrica de estrella del norte para las relaciones con los desarrolladores?

Cada programa de relaciones con desarrolladores tiene una opinión diferente sobre cuáles deberían ser sus métricas estrella del norte para medir el éxito de su plataforma. Algunas métricas son válidas, mientras que otras pueden ser lo que se denominan métricas de vanidad . Esta publicación analiza qué métricas debe o no debe rastrear.

Que medir

El objetivo de las relaciones con los desarrolladores es garantizar que los desarrolladores externos puedan aprovechar su plataforma para crear algo de valor. El valor es una idea subjetiva, pero algunos ejemplos incluyen el envío de una nueva integración o complemento que aumenta la usabilidad de su producto o la integración de sus API y SDK en sus aplicaciones web o móviles para brindar una mejor experiencia a sus clientes.

Métricas falsas de North Star

Debido a que el valor es difícil de cuantificar, algunos programas de relaciones con desarrolladores recurren ingenuamente a métricas de marketing como visitas a páginas y registros. El problema con estas métricas es que el registro de un nuevo usuario no garantiza necesariamente la creación de valor. También puede piratear fácilmente estas métricas ejecutando una gran campaña de Google AdWords o Facebook para generar una afluencia de registros aleatorios. Sin embargo, esos usuarios nunca integrarán ni aprovecharán la plataforma. Para medir realmente el éxito de una plataforma, debe observar dos métricas de estrella del norte:

  1. Tokens activos semanales (o usuarios activos semanales)
  2. Hora del primer hola mundo

1. Tokens activos semanales (WAT)

Para medir el éxito de una plataforma, en cambio, deberíamos mirar el uso. Esto puede provenir de las diversas API y SDK que ha lanzado para que los desarrolladores externos interactúen con su plataforma. El mero hecho de generar una clave de API no mide el uso, ya que incluso los no desarrolladores pueden ver las claves de API sin ningún uso real para ellas. Por lo tanto, recurrimos a los tokens API activos semanales.Dado que la mayoría de las API limitan el acceso a los usuarios autenticados, podemos rastrear cuántos tokens distintos acceden a nuestra plataforma de API en una semana determinada. Dado que un solo cliente puede crear varias claves de API con varios alcances y fechas de vencimiento, podemos reducir esto a Empresas integradas activas semanalmente. Todos los miembros de su equipo de relaciones con el desarrollador deberían tener en cuenta esta métrica al decidir dónde invertir más tiempo. Para hacerlo, debe tener la instrumentación para vincular métricas como tokens a la información demográfica del desarrollador, como los canales de marketing que llevaron al desarrollador a su sitio, la afiliación y el tamaño de la empresa, e incluso información social como las estrellas de GitHub. Con esta información, puede desglosar WAT para encontrar lo que más contribuye a su métrica de estrella del norte .

Lea también: 5 errores frecuentes de la comunidad de desarrolladores (y cómo solucionarlos)

2. Tiempo para el primer Hola mundo (TTFHW)

Seguido de tokens activos semanales, Time to First Hello World (TTFHW), es un buen indicador del éxito general de su plataforma. No solo incluye adopción y uso como WAT, sino que también incluye otras áreas funcionales fuera de DevRel, como marketing y soporte. Cuanto más tiempo se demore un desarrollador en comenzar con su plataforma, es menos probable que tenga éxito. La documentación que es difícil de entender, los próximos pasos poco claros en la incorporación o las API y los SDK que requieren una conferencia de seis horas solo para comprender los conceptos básicos son elementos que pueden contribuir a un TTFHW más alto de lo deseado. Obtenga más información sobre TTFHW y el embudo de desarrollo. Un programa DevRel eficaz debería funcionar para aumentar los tokens activos semanales (WAT) y reducir el tiempo hasta el primer saludo mundial (TTFHW).

¿Dónde se ubican las relaciones con los desarrolladores?

Dado que el objetivo de las relaciones con los desarrolladores es garantizar que los desarrolladores puedan crear algo de valor con su plataforma. Se debe tener especial cuidado para garantizar que los objetivos de DevRel estén alineados con el departamento en general. Al ser un campo relativamente nuevo, cada empresa tiene su propia idea de dónde debería residir DevRel y de dónde debería provenir el presupuesto.

Márketing

En algunas empresas, las relaciones con los desarrolladores son una extensión del marketing . Debido a esto, estos equipos de DevRel tienen el lujo de un gran presupuesto publicitario y pueden promocionar la plataforma en todas partes, desde Facebook Ads hasta una gran presencia en conferencias. Las métricas clave para el equipo de marketing incluyen visitas a la página, registros y prospectos calificados de marketing (MQL). Sin embargo, estas métricas no están alineadas con el equipo de relaciones con el desarrollador para ayudar a los desarrolladores a interactuar y encontrar algo de valor con la plataforma. Por lo tanto, estos equipos son efectivamente un equipo de marketing técnico o de desarrollo sin mucha parte de las relaciones .

Ingenieria

En otras empresas, las relaciones con los desarrolladores son una extensión del equipo de ingeniería. Estos equipos son responsables de la documentación de API actualizada y, posiblemente, de los SDK. También pueden depurar y solucionar problemas que los desarrolladores pueden encontrar o crear guías y ejemplos adicionales que pueden ayudar a su comunidad de desarrolladores. Desafortunadamente, estos equipos pasan la mayor parte de su tiempo interactuando con otros compañeros de su empresa en lugar de con la comunidad en general debido al flujo constante de cambios en el SDK, actualizaciones de documentación, depuración, etc.

Producto

La misión de un equipo de producto es construir un producto que los clientes (o desarrolladores) realmente adopten y utilicen. Constantemente están probando varias hipótesis y construyendo una hoja de ruta de características basada en datos de análisis de productos y comentarios cualitativos de los clientes. Los equipos de relaciones con los desarrolladores recopilan constantemente comentarios de los desarrolladores para influir en las hojas de ruta, mientras que son los primeros en saber si hay algún resentimiento en su comunidad por los cambios de productos. En esta capacidad, las relaciones con los desarrolladores son una extensión del Producto y más "en la comunidad" en lugar de centrarse en el lado del edificio y colaborar con las partes interesadas internas. Si bien esta es una creencia sesgada de trabajar con múltiples compañías de plataformas y equipos de relaciones con desarrolladores, hemos visto que DevRel puede funcionar mejor cuando se alinea con el Producto en lugar de otras áreas como marketing e ingeniería.

Relacionado: Cómo tratar su API como un producto

Pensamientos finales

Cualquier programa nuevo debe tener las métricas adecuadas que orienten la misión y los objetivos del programa. Los equipos de relaciones con los desarrolladores no son inmunes a la responsabilidad. Sin embargo, el historial operativo limitado de los equipos de relaciones con desarrolladores ha creado un sistema ad hoc de métricas prestadas de otros departamentos en función de la procedencia del presupuesto de DevRel. La creación de métricas de productos como los tokens activos semanales garantiza que DevRel esté alineado con ayudar a los desarrolladores a interactuar y encontrar valor en una nueva API o plataforma.

Publicar un comentario

0 Comentarios