DevRelはマーケティング活動なので、その戦略の立て方としてAARRRモデルが良く用いられます。つまり以下のような考え方です。
さらに、このモデルをDevRelに寄せた、AAARRRPモデルというのもあります。これはNexmoが提唱しているモデルで、以下のような考え方になります。
いずれもファネルを前提としています。つまり、ステージが進んでいくと徐々に対象が絞り込まれていくという考え方です。この考え方は、アプリマーケティングなどでよく見かけます。ダウンロードした段階から、課金ユーザになる段階までにおいて、どのステージでドロップするユーザが多いかを分析し、改善することで最終的な課金率を改善するという考え方です。
決してAAARRRPモデルが悪い訳ではないのですが、対開発者で考えた時にこのモデルが最適であるかというのには疑問がありました。特にReferrer(宣伝)要素が気になります。DevRelでは特に開発者による宣伝であったり、他のユーザを巻き込む仕組みは用意されていないことが多いです。他者を巻き込んだから、課金するという人は多くないでしょう。これは一般ユーザがゲームなどに課金する際の考え方に見えます。
そこでデベロッパーステージごとに組み替えたのが次の考え方になります。
まずは自分たちのサービスを知らない層に対するアプローチです。層としては、ここが一番大きくなるはずです。認知度は数値化しづらいため、Webサイトへの流入(ユニークユーザ数)やGoogleの検索結果などが指標になるでしょう。
認知した段階、Webサイトに訪れて、ドキュメントを読んだり、サービス概要を把握しようとします。結果として、ユーザ登録を行うまでのステップを歩みます。ここで離脱してしまう場合には、情報が適切に伝えられていない、または適切な開発者が流入していない可能性があります。
ユーザ登録が完了した段階です。一つの大きな節目ではあるものの、ただ登録しただけというケースも多いです。目的なく登録していると、次のステップに至れず、休眠ユーザになってしまうケースも多いです。いかにこの段階を短く済ませるのかが重要視されます。
利用を継続している開発者については、休眠ユーザに戻らないようにマインドシェアを確保し続けることが大事です。代替サービスに流れてしまって、自分たちのサービスから離れてしまうことも考えられます。ユーザを獲得し、利用されているかといって慢心せず、継続し続けてくれるように働きかけ続けなければなりません。
一つの機能しか使ってもらえていないのであれば、他の機能も組み合わせてもらえるように応用コンテンツを用意したり、代替サービスからユーザを奪えるような新機能開発も望まれます。
継続して利用している場合、何らかのアウトプットが行われます。自分たちでもサービスをローンチしたり、製品という形になって現れます。この達成する瞬間こそDevRelの醍醐味とさえいるでしょう。
できあがっている製品が少ないのは大きな問題です。できあがっていれば、それを事例としてコンテンツ化し、次なる「知らない」開発者に対してアプローチできることでしょう。
このループでは各ステージにいる開発者が次のステージに移動できるよう、施策を立てていきます。
この最後の作ったステージの成果物は、最初のステージ(未知の開発者)に対するコンテンツとしても利用可能です。一度達成した開発者は再度継続のステージに降ります。継続から登録のステージに降りるのは危険ですが、達成から継続への移行は問題ありません。
開発者コミュニティとこのループを比較すると、ステージが進むにつれて関連度が高くなっていきます。情報を受け取る側から、徐々に発信側へと移り変わっていくのが理想です。
開発者ステージにおける考え方としては、拡散であったり、課金といったフェーズをAARRRモデルから取り除いています。ブログなどを通じた発信は大事ですが、それはステージとは別物で考えるべきでしょう。課金も同様で、開発者向けのサービスではいかに無料で使い続けるかにこだわる開発者もいます。課金率を引き上げる施策は別途検討すべき課題といえるでしょう。
DevRelの施策を考える際には、施策がどのステージの開発者に対して訴求するものであるかを考えましょう。それによって測定方法であったり仮説検証が明確になるはずです。
MOONGIFTではDevRelのサポート、アウトソーシングを承っています。DevRelでのお悩みについてはお気軽にお問い合わせください。
メールにてDevRelに関するニュース、アップデートをお送りします。
Contact is below.