ℹ️ This page is the single source of truth for all administrative tasks, templates, and project management needs focused on GitLab brand social channels. If your question is "how?", the answer will be here.
Epic Roadmap Issue Board by Milestone Issue Board by Assignee
Many requests for social media coverage could sound like one ask, but ultimately have different end-user objectives or where we'll need to promote different assets or links. Please keep the following in mind to help us better manage requests.
ℹ️ For an anything to get promoted on social, there must be a dedicated social issue. Most campaigns with multiple activation points also require an epic. Not sure what you need? Message the team in the #social_media_action Slack channel.
Head to the corporate marketing project and create a new issue with the best template below.
General Request Listening Report Requests Reporting Requests
Epic: GitLab Events Issue: GitLab Owned Event Template for CFP, Reg, or Engagement Issue: 3rd Party Sponsored Event Request
GTM Coverage Epic GTM Coverage Issue for each tactic
Case Study Promotion Partner Marketing Support
@social group, which contains the entire social team and is added to the social media - triage milestone.mktg: 202x-xx-xx milestone according to when the work is expected to be completed or when there needs to be another touchpoint between the social team and the requestor. Milestones are best viewed on an Issue Board like this one. This expresses a timeline easier to understand workloads.GitLab's blogs play a vital role in brand social's success, particularly from the POV of topics that go deep into technical specifics. While we do not share posts for 100% of blogs published, we do share approx. 90% of blogs that are published. There is no set of determining factors as to which blogs we ought to share which we don't share. These specifics are subjective and usually accompanied by details from the editorial team that help us to understand the context of the blog. E.g., if a blog is published solely for SEO or other marketing needs, the content of the blog is likely to be useless for the majority of social followers, so we'll decide to skip it. On the opposite side, if a blog is tied to a GTM campaign, these are almost always shared on brand social due to usually being true-top-of-funnel content that social audiences would benefit from. From the social perspective, the critical question to answer is, "would our audiences benefit from seeing a link to this blog? How?".
Below is the workflow for publishing blogs on brand social channels.
Key parameters on sharing blogs
The social team does not create or own the core messaging for GTMs. We'll take campaign manager approved messaging, apply the GitLab tone of voice, and include social practices.
We use the following workflow to make sure teams are aligned and able to organize effectively.
GTM Campaign Manager should create a new issue, fill out the details, and attach issue to GTM tactic child epic. This means that for each new piece of content (or tactic), there should be a new social request issue.
For each new reporting period (Quarter of Half); the social team will open a new organic social child epic. We'll use this child-epic as a repo after the work on an issue is completed. Since tactics (webinar, whitepaper, etc) each have their own child-epic already, we'll execute the work with an issue attached to these epics, close the issue and move to our social epic for record keeping.
In order for links to be successfully shared on social media, there are a few elements that are required to include in GitLab-owned pages including the handbook, all marketing website links, and even "3rd-party" sites we operate like Meetup, Hopin, and other sites for user registration and events.
These elements help to populate the opengraph, sometimes called a social sharing card.
The social team may reject any request to share links in social posts that do not include these elements
There are a number of reasons these elements are required. These elements…
The elements are:
See below for code that can be added to the frontmatter of all pages. If you're using a "3rd-party" GitLab owned instance like Hopin or Meetup, these sites automate this need when you attach a core image, include a title in the event/page, and other elements.
No matter the circumstance, the social team will need a visual asset to accompany our posts. In many cases, it's most effective and time efficient if these images were created with the linked page development and added to the frontmatter before publicizing the link to teams who need to use it for promotional efforts. When there is not an image already embedded in the frontmatter of a page that GitLab owns or operates, the social team can either spend time creating our own images or reject the request. In many cases, it won't be an appropriate use of time for the social team to create our own images.
Need help? Reach out to #social_media_action Slack channel.
When sharing a link on social media, all channels will look for opengraph frontmatter information, allowing the sites to pull a social media sharing card. This includes unique specifics for the page like its title, a description, and a unique image. It's critical that all pages intended to be shared across social media sites have this informaton attached, so that our users are aware of where we're linking them to, as well as, following best practices.
Social Media Sharing tags are set by the post or page frontmatter. Please use the following template and add it to the frontmatter:
title: your page title/cta
description: page description
twitter_image: "/images/opengraph/file-name.png"
twitter_image_alt: "describe the image being used here"
twitter_site: "gitlab"
twitter_creator: "gitlab"
Be sure to update the title, description, twitter_image, twitter_alt_image, and other non-social tags necessary for your page. The twitter_site and twitter_creator tags should remain the static value: "@gitlab"
The description meta tag is important for SEO, but it's also a part of Facebook and Twitter social cards. The description should be a short summary of the page. You can think of this as a subtitle.
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 make your description less than 100 characters, if possible.
Adding an image file to the frontmatter for twitter_image should be added to the [www-gitlab-com] project at /images/opengraph/ and must be named after the page's file name. While listed as an image for Twitter, this code works for all social sharing sites.
It is important to be as inclusive as possible, which is why providing an alternative text for your image is necessary. Image alt's provide a written summary of what is in the image for users who prefer to be read what is in the image vs seeing it, think of users who use screenreaders to read social media. Text included here should not repeat the title or description and it is not another way to add additional SEO properties - you should simply describe the image. Is the picture a group of GitLab Team Members gathering at Contribute New Orleans? Then that is your image alt text.
This frontmatter aides sites like twitter in understanding how to present additional content. When the link is shared on Twitter, a user may see content that Twitter believes is related to the one shared. This is more of an administrative tag that assists on the backend. These values will always be the same and do not require you to update them.
Frontmatter requires a merge, therefore, you'll need to include this as a step in page creation. Once merged, please test your link. Preview the social cards by adding your link to the [Twitter Card Validator], or the [Facebook Debugger].
UTMs are used to track traffic sources & reach of posts/links. All posts that contain GitLab-owned URLs must contain a UTM parameter.
Please see details in the Digital Marketing handbook. In short, it's important to outline UTM campaign, content, and other variables if you're looking to measure more deeply. Campaign section is a requirement, and is likely connected to your ongoing marketing campaign. If you have questions or are unsure how to tag a URL please reach out to the Digital Marketing team &/or the Social Media Manager responsible for the campaign.
LinkTree is bio link tool. The Social Media team uses LinkTree to drive traffic to the GitLab website. Folks will click the link in bio and have a few options to choose from before landing on a webpage. The GitLab brand Linktree is: https://linktr.ee/GitLab
At GitLab we have multiple CTA's and campaign goals. The idea here is that a LinkTree will give our community an exit route and determine themselves- on where they land. Once you click the link in bio you'll have tiles to choose from: Homepage, Handbook, Press, Blog, Get a Free Trial, etc. Tile options are a continuous iteration as they will change to reflect current campaigns.
LinkTree credentials are managed via the Social Media Vault in 1 Password. Links in the LinkTree would need to be approved by the social team, as these links are considered inventory for organic social.
Consider our labels as a way to be transparent about our work at every level of our marketing organization. At any given time and at any given level, a Team Member can recall what volume and mix of work is happening. Not only does this help the social team to better organize, but would allow our Team Members up our organization to better understand their entire team, too.
Every social media-related issue should have the following labels, each of which covers our organization in a broader look further up the chain.
More on optional labels will be available soon.
/source/community/sweepstakes in the www-gitlab-com project. Name the directory the same as the giveaway /source/community/sweepstakes/name-of-giveaway/name-of-giveaway/ folderindex.html.md file.Share your GitLab story! Tell us your favorite thing you made with GitLab tell us a time GitLab helped you out of a tight spot)Tags in Sprout enable social to measure performance outside of general level metrics. If a post needs a tag but did not get one when scheduled, we'll need to tag the posts after they've been published. While this can happen from forgetting to add the tag in Sprout, its most often related to publishing natively on channels. E.g. when we use Twitter Ads/Media Center to publish unique card content or when publishing stories in Instagram.
To tag a post after its been published:
reports tabcross-network reports categorypost performance reportOur LinkedIn Events strategy is to raise attendance from x to xx or from xx to xxx for events that would otherwise not get recognition elsewhere or when they are critical to our brand marketing efforts.
LinkedIn Events are a great way to expand awareness of GitLab ran events. LinkedIn Page Admins can use LinkedIn Events to bring their professional community together safely and in real-time. Only page admins have the ability to create events under the GitLab brand LinkedIn page.
Not every event at GitLab should have a LinkedIn Event landing page. We should be highly selective to field marketing and corporate marketing efforts. If we determine specific events for GTMs or other topics would be of interest to the community, we can add those events on a case-by-case basis.
It's also important to consider the user journey, by using a LinkedIn Event page we are adding steps to registering for an event. Therefore, when an event has an appropriate landing or registration page, especially if these pages offer rich insight to the event happenings, the need for a LinkedIn Event page becomes smaller.
It is currently unclear if performance inside of LinkedIn Events produces measureable results inside of the social team's reporting structure. In the event this data is not present, it will be difficult to decide on using LinkedIn Events for corporate events due to the lack of performance data associated with the event page itself.
In order for a speaker to be added to a LinkedIn Event, they will need to be personally connected to the admin that stands up the event page. You may know who you're working with to do this already, so it would be best to inform your speaker(s) to anticipate an invite to connect from someone on the GitLab social media team.
All of the following elements should be coming from the team member who is the event organizer. The social team is not responsible for creating a brand and purpose for the event.
If these elements aren't provided or necessary, the event imagery will be whatever the current GitLab brand profile default is at the time.
Check out the LinkedIn Events FAQs provided by LinkedIn here.
In some instances, GitLab team members who are not on the social team will have administrative access to a social channel. This makes sense when team members manage paid social advertising, create events, or handle reporting as part of their roles.
All team members, including those on the social team, who have access to an admin console on any social channel will need to prove that their accounts are secured with 2FA, preferably with an app or code generator and not their mobile device. We recommend using 1 Password, which we have access to as team members of GitLab.
When admin access is granted on channels where the available permission settings are above what is necessary for non-social team members to successfully run their tasks, there will be explicit guidelines from the social team on what and where to click and to manage so that non-social team members do not accidentally interfere with social operations.
With the availability to post to a channel, respond to users, or edit company information, comes serious risk in damaging our brand in the eyes of the community, our team, the media, investors, or other stakeholders. It's not about preventing silly mistakes, this is focused on protecting GitLab, our team members, and our community from malicious activity or other damage that could reflect on the company.
The field marketing team is enabled to use the GitLab brand LinkedIn channel to create events, so that GitLab is seen as the event organizer. If you need to connect with who the field marketing LinkedIn events admin is, please message the social team in the #social_media_action Slack channel.
The field marketing events admin can only create, edit, and maintain the events listings on the GitLab LinkedIn page and they are not authorized to write posts, edit the page or its contents, or to respond to users.
Events that are authorized to be promoted as organized by the GitLab brand include demos, webinars, speaker sessions, Connect, Commit, and other virtual and in-person events that the GitLab brand and company can and will fully support.
Events that are not authorized to be promoted as organized by the GitLab brand include: team member celebrations, non-GitLab hosted events, events where a partner is the lead and already have an event page, and promoting events or campaigns that use social good initiatives for lead generation.
LinkedIn events should only be used for events and not for campaigns. Events are defined as a specific moment in time on a calendar in which the expectation is that users will join synchronously. Campaigns are defined as initiatives that run for a longer than a specific moment in time and where users can participate asynchronously.
Please use the following hex colors to represent the channels in reports, in charts, or when calling it out in plain text.
Social Media profile assets would include profile images and banners. Banners are specific to each site and should include the latest best practices in dimensions and care for where designs appear in the asset, so that they are visibile on desktop and on mobile properly. This Google Drive folder includes existing approved assets. Note, this folder is only accessible to the communications and brand design team at this time.
The following code is required when asking for team members or anyone in the wider community to submit elements that the social team intends to create content around. Please include this on rules pages or in Google Forms, or in any location where we'd be asking for content from users.
By submitting this [INSERT WHAT WE'RE ASKING FOR AND WITH; GOOGLE FORM, ETC] with answers or uploading a video response, you are providing perpetual consent to GitLab Inc., its affiliates, subsidiaries, and agents, to use your image, story, and any other submitted materials (“Content”). You will continue to own your original Content.
You are affirming that
* you have the authority to provide consent herein
* any individuals in the Content other than yourself are over 18, know you are giving GitLab permission to use the Content, and have consented to it being used by GitLab pursuant to this license
You are giving GitLab a non-exclusive license with the right to
* reproduce the Content in any form and to use in any presentation of any and all kind whatsoever
* use your Content without giving credit to you or paying you any fees
* edit your Content prior to use
By agreeing to these terms, you release GitLab, our employees and officers, and any third-party services that we use to promote your Content from any and all claims, actions or proceedings of any kind, and from any and all damages, losses, costs and expenses, including reasonable attorneys' fees and expenses relating to or arising out of the use of your Content as contemplated by this license.
You may revoke this authorization at any time by notifying [legal@gitlab.com](mailto:legal@gitlab.com) in writing (“Revocation”). Revocation will not affect any actions taken prior to receipt of Revocation.
If you don’t agree to these terms, no further action is required and you may [INSERT ACTION TO DENY; EG NOT SUBMIT THE FORM]