Content

On this page

Content Marketing

The Content Marketing team includes audience development, editorial oversight, social marketing, and content strategy, development, and operations. The Content Marketing team is responsible for the stewardship of GitLab's audiences, users, customers, and partners' content needs, preferences and perceptions of GitLab. Content marketing creates engaging, inspiring, and relevant content, executing integrated content programs to deliver useful and cohesive content experiences that build trust and preference for GitLab.

Communication

Chat

Please use the following Slack channels:

Issue trackers

Team

Editorial Mission Statement

Empower and inspire software teams to adopt and evolve a DevOps workflow to collaborate better, be more productive, and ship faster by sharing insightful and actionable information, advice, and resources.

Vision

Build the largest and most diverse community of cutting edge co-conspirators who are leading the way to define and create the next generation of software development practices.

2018 Core content strategy statement

The content we produce helps increase awareness of GitLab’s complete and single application with the goal of broadening our market share and increasing sales by providing informative and persuasive content that makes DevOps teams feel excited, curious, and confident so that they can adopt & integrate industry best practices into their workflow.

Messaging for Verticals

When to develop vertical messaging: The key is to determine if an industry has a certain pain point that another industry does not share. You need to describe the problem (using industry specific terminology, if necessary) and also how your product solves these problems for them. Additionally, you can create high-level messaging and then branch off; for example if multiple industries are very security conscious, create security focused marketing, and adapt to select high value verticals.

Checklist for good content

Requesting content and copy reviews

  1. If you are looking for content to include in an email, send to a customer, or share on social, check the GitLab blog first.
  2. If you need help finding relevant content to use, ask for help in the #content channel.
  3. If the content you're looking for doesn't exist, open an issue in www-gitlab-com project and label it blog post. The content team will evaluate if it's likely do well on the blog, in which case we will write the content. If the suggestion isn't likely do well, we will suggest you write it and we will help edit it.
  4. If you are creating your own content and need a copy review, ping @erica. Please give at least 3 days notice.

Writing blog posts

See the blog handbook for detailed instructions on how to publish a blog post.

The Content Marketing team is responsible for increasing sessions on the GitLab blog month over month. We use data-drive insights to decide what to write on using the content marketing dashboard. In order to hit our goals, we aim to publish at least 3 blog posts that will garner 10,000+ sessions.

*From 2018 blog analysis conducted in 2018-10

  1. Average sessions per month on the blog: ~30,000
  2. Average sessions per post in published month: 3,792
  3. Average sessions per content marketing post in published month: 3,500
  4. 55% of posts get <1,000 sessions in a month
  5. 27.47% of posts hit our expected outcome of 1,000-4,999 sessions in published month
  6. 28.57% of posts garner less than 499 sessions in published month
  7. 9% of posts are "hits" (10K+ sessions in published month); "Hits" don't consistently perform well over time

Breakdown by category of "hits":

Obeservations

  1. There is not a strong correlation between # of sessions and topic
  2. Strong performing content marketing posts focus on show and tell engineering stories
  3. Posts really fall into the 5,000-9,999 session bracket (3.3%)
  4. Content hack day posts tend to perform well (>1,000 sessoins in published month)

Identifying and qualifying a high-performing blog post

Qualifying story ideas:

Look for the following patterns:

  1. Team implementing a new techonology, process, or coding language
  2. Deep dive into how a popular feature is made
  3. Chronicling a performance improvement
  4. Covering a controversial decision that was made

Who and how to interview:

  1. Contact the technical subject matter expert. This can be someone who created the issue, or managed the project.
  2. Set up a 30 minute interview and dig into:
    • What was the challenge?
    • What was the solution?
    • How did you go from point a to point b? Walk me through your thought process.
    • How was the solution implemented and what is a realistic use case of the solution?
    • What lessons were learned?
    • How did this make the GitLab product / development community better?
  3. Optional: Contact the business subject matter expert. This could be a product manager or a product marketing manager.
  4. Set up a 30 minute interview and dig into:
    • How does this solution help a user?
    • What business value does this solution bring?
    • How does this solution relate to our product?

Attributes of a successful blog post:

  1. Deep dive into a hard technical challenge.
  2. Puts the reader in the shoes of the person who faced the challenge; reader learns via compelling example.
  3. Intellectually satisfying; learning compontent.
  4. Allows the reader to learn from someone else's mistake, and follows a problem/trials and triumphs/solution story arch.
  5. Taking a controversial or unpopular stance on a topic, back by hard evidence.

Examples of high-performing posts (20K+ sessions in published month):

  1. Meet the GitLab Web IDE
  2. How a fix in Go 1.9 sped up our Gitaly service by 30x
  3. Hey, data teams - We're working on a tool just for you
  4. Why we chose Vue.js
  5. How we do Vue: one year later

Conducting a blog analysis

Pull information on all blog posts for document how many sessions each post received in the month, and how many sessions they received of all time. Categorize them by type, bracket, total sessions in month, total sessions to date, category, theme, and topic. Eventually add first touch point revenue data. Search Google Drive for Blog Performance to find the appriopriate sheet to work from.

Column explanations:

Crediting blog posts

Add a note at the end of a blog post reading "[Name] contributed to this story/post" if:

Key Responsibilities

At the highest level, Content Marketing is responsible for building awareness, trust, and preference for the GitLab brand with developers, engineers, and IT professionals.

  1. Audience development
  2. Editorial voice and style
  3. Defining and executing the quarterly content strategy
  4. Lead generation

Campaigns

Content marketing is responsible for executing marketing campaigns for GitLab. We define a campaign as any programmed interaction with a user, customer, or prospect. For each campaign, we will create a campaign brief that outlines the overall strategy, goals, and plans for the campaign.

Campaign Brief Process

To create a campaign brief, first start with the "campaign brief template" (which can be found by searching on the google drive). Fill out all fields in the brief as completely as possible. Certain fields might not be applicable to a particular campaign. For example, an email nurture campaign leveraging text based emails won’t have a visual design component. This field can be left blank in that example.

Once the campaign brief is filled out, create an issue in the GitLab Marketing project and link to the campaign brief.

On the GitLab issue, make sure to:

Defining Social Media Sharing Information

Social Media Sharing info is set by the post or page frontmatter, by adding two variables:

description: "short description of the post or page"
twitter_image: '/images/tweets/image.png'

## Ensuring your Post Will Have a Functional Card and Image

When you post a link on Facebook or Twitter, either you can see only a link, or a full interactive card, which displays information about that link: title, **description**, **image** and URL.

For Facebook these cards are configured via [OpenGraph Meta Tags][OG]. Twitter Cards were recently set up for our website as well.

Please compare the following images illustrating post's tweets.

A complete card will look like this:

![Twitter Card example - complete][twitter-card-comp]

An incomplete card will look like this:

![Twitter Card example - incomplete][twitter-card-incomp]

Note that the [first post] has a **specific description** and the image is a **screenshot** of the post's cover image, taken from the [Blog landing page][blog]. This screenshot can be taken locally when previewing the site at `localhost:4567/blog/`.

This information is valid for the entire website, including all the webpages for about.GitLab.com, handbook, and blog posts.

Images

All the images or screenshots for twitter_image should be pushed to the www-gitlab-com project at /source/images/tweets/ and must be named after the page's file name.

For the second post above, note that the tweet image is the blog post cover image itself, not the screenshot. Also, there's no description provided in the frontmatter, so our Twitter Cards and Facebook's post will present the fall back description, which is the same for all about.GitLab.com.

For the handbook, make sure to name it so that it's obvious to which handbook it refers. For example, for the Marketing Handbook, the image file name is handbook-marketing.png. For the Team Handbook, the image is called handbook-gitlab.png. For Support, it would be named handbook-support.png, and so on.

Description

The description meta tag is important for SEO, also is part of Facebook Sharing and Twitter Cards. We set it up in the post or page frontmatter, as a small summary of what the post is about.

The description is not meant to repeat the post or page title, use your creativity to describe the content of the post or page. Try to use about 70 to 100 chars in one sentence.

As soon as you add both description and social sharing image to a page or post, you must check and preview them with the Twitter Card Validator. You can also verify how it looks on the FB feed with the Facebook Debugger.

Examples

To see it working, you can either share the page on Twitter or Facebook, or just test it with the Twitter Card Validator.