Anyone who has read the EveryDeveloper blog or founder Adam DuVander’s book, Developer Marketing Does Not Exist, probably already knows that marketing to developers presents its own special challenges. One such challenge is how to accurately measure and communicate the impact of your efforts. Developers are notoriously resistant to marketing practices that generate clear-cut conversions—like signing up for newsletters or providing emails tied to companies so you can judge if they fit the demographic profile and usage habits (young, tech-savvy, desktop users) of people most likely to use ad blockers. As a result, your analytics are unlikely to reflect true reach and engagement. These factors make it difficult to measure, and thus improve, the dev experience. It also leaves you struggling to communicate your program’s impact to management.
Luckily, these problems are far from insurmountable. With a little planning, a program that embraces experimentation, and an approach that measures activities corresponding to the entire dev journey and how they change over time, you can build an analytics-driven dev marketing program of which any B2C mass marketer would be proud.
But before you begin, it is important to agree on what success looks like.
When it comes to measuring the success of your developer marketing program, your focus should be tracking improvement over time of things that either:
- Matter most to how the company evaluates your project’s success (e.g. downloads, event attendance, or free account signups).
- Reflect user activities you have a strong reason to believe correlate to achieving #1 (e.g. blog engagement, GitHub stats, or docs pages read per session).
The challenge is that #1 and #2 almost always matter differently to different parts of the organization.
Boards and management tend to focus on top-line goals like downloads or sign-ups, in part because they are interpreted as leads. But these sorts of metrics don’t tell you why people are signing up, what communities or ecosystems are most engaged, or how to better serve your developers and grow your community.
So how can you get everyone on the same page, thinking not just about top-line metrics but also things like blog engagement and docs pages read per session and community slack sign-ups?
The answer is to focus on what your proximate metrics deliver: transparency, accountability, and a path to continuous improvement.
These are activities that your developer marketing team can refine through disciplined planning and experimentation. You can provide a roadmap to get better and demonstrate your success over time.
Once you start to measure and share analytics on activities in the developer journey, it is tempting to set arbitrary goals like X% growth in page views per quarter. This should be avoided.
Goal-seeking of this nature is anathema to long-term thinking. You will begin to plan to hit goals rather than deliver a great experience that leads to top-line success. It is enough to say you will plan, measure, experiment, learn, and improve.
Another way to get everyone at your company on board with your program is to make and share a plan, and specifically for this discussion, a content plan.
Telling other teams and management what you are planning to do, doing it, and sharing the results provides vital context for everyday developer marketing activities that ultimately result in top-line achievement. Reviewing results side-by-side with the plan also demonstrates the value of activities (and the team pursuing them) over time.
If you’re going to share your plan, you need more than just the activities you’ll undertake. You should also include why you’re undertaking them. In the context of content, I recommend organizing your content plan in terms of what EveryDeveloper calls content concepts.
Pick concepts that map to your team goals—developer zero-to-one, use cases—and events fixed in time you need to support—new product launches, hackathons, a company-hosted annual developer event. You don’t want too many concepts because you a) don’t want to spread yourself too thin covering lots of topics and b) the goal is to track and assess performance. Concepts create focus and results are easier to share.
Quarterly and annual planning docs can be difficult to make relevant to day-to-day activities. For a number of reasons, including convenience, I ended up adapting the content calendar for this purpose. It also makes sense because of the role content calendars play in driving engagement itself. As a developer relations director I worked with once said, developers will keep coming back to sites that regularly and frequently publish content relative to the problems they want to solve.
With a few additions, a content calendar becomes a tool not just for planning content but coordinating that content with other activities, showing results, and experimentation.
The foundation of a content calendar tracks the who, what, when, where, and why of content:
- who – in this case, I mean target audience; of course, you’ll want to track the author(s).
- what – a very brief summary of message; what you’re talking about.
- when – that’s why this is a calendar.
- where – what channel(s) will this be delivered on.
- why – what is the reason for this piece of content; what important use problem does this solve?
I then add the following columns:
- concept – covered above, concepts make it easier to organize and assess performance.
- keywords – does this mean SEO? Kinda. For now, suffice to say it is important to see what terms are associated with better performance. This is one of the places you’ll do some experimentation. And remember, use terms that describe the developer problem you solve in terms they’ll recognize. Don’t just use terms that describe your product.
- outside events – track conferences, product releases, and whatever else you’ll need to account for in your plan
- analytics – whatever your core analytics, track them here. At minimum for content, I track views, inbound links, time on site, and bounce rate. You don’t have to track everything here. Just enough to get an idea of what is working. You’ll want to do more of that.
- views – I also think it is useful to track views at 30, 60, and 90 days. Everyone has that one blog that does steady numbers. Tracking the long tail of views tells you which blogs have staying power.
The images below extend on the sample calendar in a previous blog (Build a Technical Editorial Calendar You Will Actually Use) with the addition of the Concept, Keyword, Events, and a basic version of 7-, 30-, and 60-day analytics data.
With these additions to your content calendar, you are now sharing plans and results, along with demonstrating your team’s contribution. The final thing you want to show is improvement. And improvement means trying new things, taking risks, and experimentation.
NOTE: Google Sheets offers a Google Analytics add-on that allows you to pull data directly into your content calendar, including data from custom reports. It’s worth exploring if you use Google Analytics (or Sheets) and your company can provide you access. Since the data doesn’t need to be up to the minute, it is more of a convenience than essential.
If you’ve planned your concepts, researched the keywords that best describe the problems your developer audience is trying to solve, and have a calendar, now you can start experimenting.
Make experimentation part of the plan and communicate experiments to your team and management. As a CMO, I love seeing every fourth or fifth blog or video try something new.
It doesn’t have to be radical new concepts either. This could include the way you organize content (e.g. shorter sections and more headers that telegraph intent or dividing long code blocks with more explanatory commentary), spending a little extra time/money on a designer to create nicer illustrations, capping word count for a month, or creating an audio version of the blog where applicable.
Try new things but don’t try too many new things. Look for patterns. Don’t give up after one iteration of an experiment. Sometimes it takes a few repetitions to see if a change is making a difference. If you are experimenting once every four or five blogs, for example, this means you might do fewer experiments in a year, but that’s okay.
And once again, don’t forget the long tail—signal doesn’t always arrive on day one.
If Doctor Alexander Fleming hadn’t left his experiment out over a long holiday from the lab, who knows when we would have discovered penicillin.
Throughout this article, I’ve discussed the use of analytics largely in the context of communicating your team’s impact to the rest of your company, and more specifically, management. It is critical to arm yourself with the best possible data linking your activity to outcomes so that management can justify continued investment in your programs and your team.
But I don’t want that emphasis to come at the expense of the ultimate goal: delivering a great experience to the developers you serve through your blogs, videos, documentation, and events. Time spent getting management buy-in, even if it takes a lot of education, ultimately tapers off. The approach outlined here—planning, experimenting, measuring, refining the experiment—will serve you long past the time when you’ve successfully educated internal teams, providing you and your team with the framework for a disciplined and scalable program.
If you’re in the market for more personalized help in reaching more developers with your marketing program, get in touch with the EveryDeveloper team. They understand your technology and offer integrated content strategy and production.
About Antony Falco
Interested in the intersection of good writing and analytics. Came late to marketing, by way of support and solutions engineering. Motivated by the idea all three are connected by a need to communicate complex ideas unadorned of needless jargon and that great service starts with the words you use. I also believe the novel “JR” by William Gaddis is not as tough as everyone says and am certain you will enjoy it.
Find Antony on LinkedIn.