Like panda888888 said, DevRel in an ideal world is less about metrics and more about listening and building relationships with your community, but as we all know, metrics are still necessary to prove business value and to keep the team alive within a company.
I wrote a whole book about how to determine and show the business value of DevRel at your particular company (http://persea-consulting.com/book) but there are two main points I'll highlight here:
1) When reporting success to stakeholders at your company, focus less on the work output (how many conferences did you speak at, blogposts did you write, etc.) and more on the goals that those tasks pushed forward. What's the purpose of the blogposts? Are you trying to improve your audience's onboarding experience by writing tutorials or sample applications to help them understand various uses of your product? Are you speaking at conferences for brand awareness purposes or to popularize the key principles that your product is built upon? Focus on those topics instead of "I did `x`." For instance, focus on how many fewer support tickets were decreased as a result of your tutorial or improved documentation.
2) Make sure that your goals are aligned with the company goals. Your team mission should point back to the overarching company goals in a way that it's clear the work that you're doing will further the goals of the company. (Note: If you don't have a team mission, you should! I wrote an article about that here: https://cmxhub.com/follow-the-north-star-creating-a-communit...) Your value comes from building relationships with a technical audience over a longer period of time, which means you'll need to show how the work that you're doing is beneficial to the company in the present day as well as in the future, but through your mission and goals being aligned with the rest of the company, the stakeholders should be able to see that while perhaps non-traditional, the work that you're doing is beneficial.
