Using data to inform your content strategy can give you insights into what to write, who to write to for and when to publish. Nexmo’s Martyn Davies talks about how to capture, analyse and harness the wealth of data that is available to you.
Hi, everybody. Thank you for finding your way down to the IBM room to listen to me talk about numbers and stuff for the next 20 minutes or so.
So, I wasn’t expecting this room to be quite so purple when I walked into it. I’m very glad that it’s now been filled up with more people, so many of them wearing blue hoodies that look very similar to this. Thank you. Thank you, team, for your support.
So, I’m Martyn Davies. I work at Nexmo. With the exception of the people that work there, who’s heard of Nexmo, by show of hands?
Okay, good. I’ve been in developer advocacy, as Carla said, for quite some time now. I’ve worked at a couple of different companies, and one of the things that’s been quite a constant through a lot of the time that I’ve spent there has been the work that I’ve done on content and engaging with developers in ways that don’t necessarily involve standing up on stage and talking Most predominantly through the written word, but a little bit more recently forays into video and some other things in live streaming, as well, which will be happening soon.
So, what we’re going to talk about a little bit today is a combination of two things, content strategy and data. And just so we’re clear, when we talk about content strategy, this is effectively what we mean. Content strategy refers to the planning, development, and management of content, written or in other media.
We’re going to add data into that mix, as well, so that the planning, development, and management are a little bit easier. Because one of the things that I see across a lot of the things that we do, and at a lot of other companies, as well, is that even this bit isn’t written down for a lot of people.
And a lot of strategy when it comes to content in developer relations, is still this: just write all the things and hope that people read it. And maybe it gets picked up. And perhaps your SEO juice goes up. And maybe someone posts it somewhere for you that then gets you a whole bunch of traffic. Which is fine, but at a certain point, it’s going to run itself into the ground, and you’re not going to know why, but you’re also not really going to be able to approach it in a way that means that it’s making a lot of sense.
So when you stand up in front of the people that are paying your salary and they ask you to justify some of this stuff, you’re going to be like, “But our strategy was just write all the things. Look, there’s even a meme in the background.” It’s not going to fly. When you’re putting this together, this pulls up a whole lot of questions in the first instance that you need to try and answer.
When you’re designing a strategy, typically you’ve got to try to figure out the answers to some of these things. So, for instance, who the content is for. You know, are you a self-service platform for developers? Are you looking for developers at larger companies that you’re only going to sell to 200 seats or more? What problem is the content that you’re going to be putting out there going to solve for people?
You need your content so you can get the eyes, but why do you want them? What problems are you going to take care of that means that people read it? And what value are they’re going to take away from that? Where is it going to live? Is it going to be on your company blog, or are you going to post the majority of stuff on external sites so that people could discover you there?
Maybe it’s video content. So, is its home going to be YouTube? Are you going to live-stream on Twitch? Where is it all going to live? And who’s going to write it? Do you have a team of people that are crying out to be writing content or making videos or is it just one of you? Are you the sole person on your team at the moment that needs to take care of this stuff?
You need to think about the programming languages that people are going to be using to interact with your services. You need to think about those technologies, and also how much time you can dedicate to this in a consistent manner so that it isn’t just sporadic and putting a post up here, and putting a post up there, and then three months later something else. And then, finally, how are you going to get people to read it?
The meat of this, getting those eyes on so you can increase the awareness that is so important to what we all do? It’s a lot of questions. And unfortunately, those questions beget more questions. If you just dig into who the content is for, here’s more. Do you have one API or many?
Are the APIs your product or are they supporting the product that you have out there in the first place? Do you have client libraries? What kind of developers are you looking to reach? How quickly can a developer get to “Hello World!” with your product? It’s a lot. If you were going to sit down and think about all of this stuff, you really need to do it from a point where you can actually make some decisions with data.
It’s questions, questions, questions, but it’s worth running through these. Answers can be hard to come by, but knowing where to look, and digging into the data that will help you form part of the strategy and give you a baseline to begin with, will be a great start. So, we’re going to look now at how some of the data can actually help you answer these questions and where you can find what it is that you need.
So, let’s dig through the questions. Who the content is for, plus data. We talked about whether or not you maybe have client libraries. So, say you look at the traffic for the client libraries that are pushed into the API. You’ve got logs, right? You know where to find this stuff.
Say your PHP library is driving a lot of traffic, but your node library isn’t doing so well. Do you focus on writing more PHP content because that’s popular? Or do you focus on writing more node content because it hasn’t found its audience yet, and maybe you need to drive more people at it? Take a look at what’s been written previously. Look at the analytics around what you’ve done in the past.
Has it been getting a lot of traffic, and has that traffic been flowing through to GitHub for installations? Has it been flowing through to documentation? Conversely, if you’re looking to grow popularity, then maybe you do double down on what it is that’s already been written. Maybe it’s popular, but the numbers aren’t stellar.
So, maybe then double down on what’s being written about it, give people more insight on what can be done with those APIs, what actually is possible, what you can do that will inspire them to try and interact with it in more ways. By looking at the logs around your API interactions from the client libraries, you can get an understanding a little bit of what it is that people are actually doing with your APIs.
You can start to figure out some of the use cases that people are solving. Now, that’s great for those people that have solved it, but what about people who maybe are having that similar problem, and also want to try to solve that, as well? Can you pull stories out of the logs for your APIs? Can you put that stuff into the written word and generate tutorials, or how-tos, that will sit inside your documentation, or in your blog, or elsewhere, that are going to help drive traffic?
Are people talking about you on Stack Overflow, either in a good way or a bad way? If they are, that’s good because you can pull inside out of this, as well. If you have a lot of people that are going on there, and quite clearly they’re having problems getting started with what it is that you have to offer, then you need to increase the amount of content you have around doing just that, whether it’s in your documentation, or whether it’s on a blog, or any other channel.
If you have people that are digging on very specific aspects, but they’re falling over with a particular client library, then that speaks to maybe having more interaction around that particular documentation. Finding ways to solve that problem and put it front and center so that when people are looking for it, you can go in there, answer the question, give them the value that they need, but also link out and say, “Look, we’ve taken this and we’ve solved it, and you can find that information here.”
Because thinking particularly about something like Stack Overflow, it is a content source. It ranks really highly on pretty much everything. It’s usually within the top three to five when you Google any kind of problem with any kind of service at any point. It’s everlasting, but a lot of answers go out of date. So, you can also ensure that if you do take inspiration from this, go away and write something else that then solves the problem that has been asked on Stack Overflow, go back and update the answer so you include it in there, so then you complete the cycle. If people are looking for it in the future, they’ll find the piece of content that maybe is on your blog that drives people through to that point, and then to their onward journey from there.
A very baseline, particularly with something like Stack Overflow, just look at what tags they’re using. If they’re having a problem, have they also tagged it with particular frameworks? Have they tagged it with particular languages? If you grab and store this stuff from the Stack Overflow API, you can very quickly start to generate trends and start spotting themes that are coming out of this.
So, what problems can you solve? If you’ve got regular issues that are coming through your support channels, then you should be making a note of this kind of stuff. Build yourself a table, find a way to store the issue type, the technology that’s being used, what level the developer is at, so you can start adding this into the ideas list for the pieces of content that you could be putting out there.
Similarly, if you don’t have a support team that’s particularly great, and always runs to you to get those answers, then having that stuff there so they can throw back means that that will probably happen less. You’re finding your documentation SEO ranking isn’t as good as you’d like it to be.
You’re finding gaps in people’s journey, finding gaps in people’s knowledge. They’re not finding what it is that they maybe need within that or the documentation is too verbose and overwhelming for a lot of people. You can break down a lot of what is in your documentation into how-do-I-do-X-with-Y type posts that focus specifically on achieving one thing with another thing.
Typically a framework, or a particular language, or a client library. It’s a jumping-off point that picks up nicely because a lot of these posts rank very well because they are titled and written in such a way that they track better with the way that people actually search. Your documentation may not. You find that looking at your client libraries, that actually you’re getting a lot of signups, but then people aren’t doing anything.
You’ve low activation rates. But you know that, maybe within the first seven days, they do something and then they drop off. They do stuff within their first 30 and then they drop off. Or they do something within the first month, maybe a couple of times, but then after that they drop off. By looking at that data, you can start to define at what point people are either losing interest, not finding what they need, or just need some more inspiration about how they can do things with your product or service.
So then you can take the content that you’re pulling together, throw it into targeted emails at these points. You know by looking at these rates of activation, which buckets you can start to pile your new subscribers, your new users into so that you can then target them more specifically with something that hopefully is going to get them back on track.
And more importantly, have you ever Googled yourselves? Not like, you know, Googling you as a person, but have you Googled your company? Have you seen what people actually search for? Have you ever looked inside your Google Analytics dashboard and taken a look at the search queries that people have used to arrive on your site or your blog?
Some of them are a madness, but it’s useful. Because if that happens enough, then, you know, maybe you never realized before that actually you were the number one API for cheese, but now you do. How do you retarget that content? How do you take something from that and then add it to that mix, so the next time someone is searching for the fromage API, you’re right there?
Make sure that you also include your competitors and other aspects of your industry when you’re doing that kind of thing as well, if you can, particularly when it relates to cheese. This is some Nexmo-related examples of what I’m talking about when we discuss this kind of X-with-Y type content.
So, this is stuff that’s happened over the last couple of months on the Nexmo blog. And you can see that, you know, these are all relatively Googleable. You know, if I’m looking to do a WebSocket server with Java, we’ve got a post for that. If I want to handle keypad input with Java, we’ve got a post for that. Want to receive a phone call with Java? Got a post for that.
These are pulled out of the documentation that we already have, and they’re linked directly through to that. But if people are in Google, they’re probably going to ask their question very similar to these. They’ll find this stuff, and then they’ll begin their journey within the Nexmo world from there.
So, what channels do you publish and promote, and how can data help with that? At the very least, you’ve got Google Analytics, right? Please nod. Some people at the back just, like, very quickly adding it in now. That’s fine if you do it today, it’s all good. After this point, it’s great. Looking back at traffic that you’ve had on anything at any point with the source medium parameter turned on is going to show you a lot about who’s pushing traffic at you, and where it’s coming from, and how much of it, and how often.
You go through that and build yourself a list of sources, then you’ve got a way of being able to reach out to these people when you put something new and ask them to promote it. You also know who it is you should be targeting because they’ve already pushed traffic at you once. When you’re pushing out traffic elsewhere, most people don’t add the UTM tags to those links, which actually add a huge amount of value to this first point right here.
And you can tell a lot, just generally, because Google Analytics is a relative good product for this, but the more you include in those URLs, the more information you’re going to get out of it. From that, you’re also going to be able to tell things like which emails drove the most traffic, which sites drive the most traffic for Node.js.
You also need to think about experimenting where your audience is. A lot of people too quickly focus on publishing any piece of content directly on their own domain, or on their own blog, which basically assumes that people already know who you are, and what you do, and why they should already be using you.
Which is fine. If that has happened, then great, all power to you. But it’s also a good idea to consider when building this strategy where you’re going to be publishing, types of content, where your audience already exists, so that you can capture them from that point and pull them over to you.
And then, also, don’t fear paid placements. There are some good sites out there where you can pay to have pieces of content put together that are good and do drive traffic. But make sure that when you do that, you know how much you spent and how much is coming back in terms of those traffic so you could basically figure out what that cost per acquisition was. Because if you go to marketing and say that it was a thousand dollars for one person to read it, they’re going to cry and they won’t want to play with you anymore.
Okay. So, who’s going to write it? You and your team, obviously, in the first instance. Mark, you’re up next.
But you should also be considering what external writers are out there, as well. Who’s written about you in the past? Who has articles elsewhere that mentions your product or service that are digging into your API? You can get this from source media information as well. You can be reaching out to them and start to build out a content community that can help add in the frequency of posts that you’re getting out there.
Because it’s tough getting, you know, even weekly posts out with, you know, a team of even a couple of people. But if you have more people elsewhere, then that’s all good. And this is something that Carla and Matthew mentioned before in their talk, as well. And if you haven’t seen that, the video will be out soon, so you can check it. If you’ve got super-helpful members in your Slack community, you’ve been looking at the interactions that all of the different members within your community have been taking place, who’s helping people on a regular basis?
Who’s answering questions around this particular topic? Who’s answering questions around this particular framework? Who seems to be really good with this client library? Keep a note of all of this. Because these are the kind of people that you could be reaching out to and saying, “Would you like to write something for us, too?” Look at who’s submitting pull requests on your open source, as well. Are they contributing regularly?
Are they putting in stuff that’s actually taking what you’ve got out in the world and taking it to the next level? Are they adding stuff that might make you want to hire them? As part of that, maybe you want to have them write something for you first. And then, how do you get people to read it? You build a list of newsletters and external outlets that you can reach out to.
Double down on the traffic that you get from that. Was it asked on Stack Overflow or another forum? Go back and make sure that you include anything that you write in those answers. Use it as part of onboarding emails. If people are signing up for a service, if you’ve got, you know, someone signing up that likes to use Node, and has used this particular API, pull out the top three posts that have ever been written on that particular subject and send it to them in an email, with a nice thank-you and a very nice note.
And link it from Docs and include it in there as tutorials as well, because it will be useful in addition to what’s already there. If people are feeling like actually it’s a little too verbose and it’s not necessarily making sense for them. Something that’s a little bit more specific that guides them through will be helpful. So, to quickly surmise, over, like, 30 seconds maybe, is you can find data to generate ideas for content strategy in API logs.
You can find them in Stack Overflow. You can find them in support tickets. They are in your Slack community. They’re there in the search queries. They are part of your site traffic and click tracking. But if you don’t look at all of this stuff, you can never pull out the stories that need to be told. So, you add all of this stuff to a shared Google Doc. At the very least, pull out stuff from this and put it in a Google Doc of ideas that you share with your team or your external contributors.
So, where do you go from here? You’ve got multiple data sources, you’ve got content analytics, you now have a plan of how to compare and act on them. You will soon have a nightmarish mangle of numbers that will ultimately become difficult to maintain and cause sleep loss and fear of Excel.
When this point happens, I’m afraid, friends, it is dashboard time. But we do not have time to go into that now, because my time is up. So if you would like to know more about how you dig into this, as well, then please do send an SMS to this number and you will be sent a link at which there is five more slides to this talk that you can read afterwards.
International folks, that’s your number at the bottom there. I’ll give you one more minute with that. Thank you very much. I will be taking questions out there afterwards at some point. Thanks, everybody.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?