Social Media Project Management and Admin

Social Media Project Management

Epic Roadmap Issue Board by Milestone Issue Board by Assignee

Requesting Social Promotion

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.

Open a new issue to request social coverage

Head to the corporate marketing project and create a new issue with the best template below.

General Request Templates

General Request Listening Report Requests Reporting Requests

Event Request Templates

Epic: GitLab Events Issue: GitLab Owned Event Template for CFP, Reg, or Engagement Issue: 3rd Party Sponsored Event Request

GTM Templates

GTM Coverage Epic GTM Coverage Issue for each tactic

Other Specialized Templates

Case Study Promotion Partner Marketing Support

Things to remember about social media requests

• Sometimes it is not possible to schedule posts when desired due to any number of reasons, but the social team will work with you to make sure you’re supported.
• The social team reserves the right to not publish for a myriad of reasons including crisis moments, calendar priorities, and other elements. We’ll do our best to explain why when asked.
• If you haven’t done so already, consider GitLab’s Social Advocacy Program as an additional resource for amplification. Advocacy allows your marketing messages to be given to GitLab Team Members to share on their own personal social media channels. If your team does not have a designated curator, you can suggest the piece of content through Bambu for approval.

Request workflows

• When a social media issue template is used, the requestor is required to fill in as much info as they have that is appropriate to fulfill the request.
• Issues are automatically assigned to the @social group, which contains the entire social team and is added to the social media - triage milestone.
• A member of the social team will see the issue in their to-do’s, and can either pick up the issue to work on themselves or discuss it with other team members about who is best equipped to fulfill the request.
• The team member who is going to do the work unassigns other team members and leaves themselves as the only assignee.
• Team member considers timelines, workloads, event dates, and other information to then assign the issue to a 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.
• Adding a due date is only required when the milestone selected is not when the work will be delivered, so in the event the milestone is another touchpoint. Some requestors may add a due date themselves. If the date needs to change from what the requestor selected, simply tag them in a comment and let them know why it has changed.

Blog coverage workflow

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.

• Social team member sees new blogs in the #content-updates Slack channel
• Social team member takes the link and heads to Sprout’s publishing settings to set the UTMs: https://app.sproutsocial.com/settings/publishing/)
• Under URL tracking, click “+add url”
• Set the parameter for campaign and save it. For basic blogs, the campaign is blog. If it can be (or is explicitly) tied to a marketing campaign, use that campaign utm. e.g., 10years, seeingisbelieving, devopsplatform. If you are unsure, ask the editorial team inside the Slack thread for the blog.
• Head to Sprout’s publishing tab: https://app.sproutsocial.com/publishing/, and schedule blog content. When you add the URL of the blog to the post, it will automatically add UTMs based on the channel and use the preconfigured campaign UTM from above.

Key parameters on sharing blogs

• Suggested copy is provided by the editorial team via the “click to tweet” box at the bottom of every blog. Please feel free to use this copy directly or tweak as desired. If there is not a “click to tweet” box at the bottom of the blog, consider reviewing paragraphs 1 and 2, as well as the last paragraph of the blog, for copy ideas
• Schedule each blog at least 1x across Twitter, Facebook, and LinkedIn, unless the blog would only benefit from key niche audiences on specific channels (e.g. community-oriented posts for Twitter, or job related ones on LinkedIn). Our audiences do have a great amount of cross-pollination, so many blogs will make sense across channels.
• Consider scheduling additional timeslots 2-8 weeks ahead of your first scheduled posts. E.g. a new product launch, timed details are included with end dates, etc. If there are weeks between posts, using the same copy is fine. However, if these posts would appear back-to-back week over week, consider editing the copy to be different.
• General blog coverage without subjective needs added may look like this:
  • Copy 1 scheduled on FB, TW, LI
  • Copy 1 scheduled on TW again in 2 weeks
  • Copy 2 scheduled on FB, TW, and LI approx 4 weeks from the original scheduled date above.
• Unless dates/times require specific publishing time windows, the specific publishing volume and timelines aren’t are important as it is to dynamically create variability in our content and our topics by mixing blogs and topics with other posts.

Organic Social and GTM Motions

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.

Social and GTM Two-Step Process

Requesting the work

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.

Social GTM Request Issue

Recording the work once it’s done

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.

Social GTM Child Epic Code

Data needed on pages in order for links to work on social media

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…

• are more inclusive due to the nature of the elements - providing additional text to describe links in place of being able to understand the content visually
• aid in building more “Social SEO”, making the link more searchable on social media channels
• utlize the basic features that express a link on social networks (titles, descriptions, images, and alt text)

The elements are:

• Page title
• Page description
• a unique-to-page-content image
• “alt text” that describes the above image for the hearing impared
• Twitter specific elements that help the channel identify authors and make our links more discoverable

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.

Adding an image embed to links for sharing on social media

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.

Canva Enterprise Account

Consider using an existing template in our Canva Enterprise account as these images have been approved to use.

Templates

• Generic Website Template
• Generic Brand Template
• Brand Specific Content with Photo Template
• Website Specific Content with Photo Template
• Big Announcement Template

Need help? Reach out to #social_media_action Slack channel.

Adding Frontmatter to GitLab-owned pages for proper social sharing

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”

Description

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.

Twitter_image

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.

Twitter_image-alt

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.

Static frontmatter like twitter_site and twitter_creator

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.

Testing frontmatter

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 for tracking URLs

UTMs are used to track traffic sources & reach of posts/links. All posts that contain GitLab-owned URLs must contain a UTM parameter.

Organic Social Media UTM Creating Sheet

Organic Social Media UTM Creating Sheet (internal)

The social team manages their own social media UTM tracking sheet. Viewable to all parties, this sheet is managed only by the social media team.

Other UTMs for Tracking

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.

Links in bio with LinkTree

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.

Labels

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.

Required Labels

Every social media-related issue should have the following labels, each of which covers our organization in a broader look further up the chain.

Organizing by line of work

• ~“Social Media” (our team)
• ~“Corp Comms” (our department)
• ~“Corporate Marketing” (our organization)

Organizing by status of work

• ~“mktg-status::plan” (net-new issues, not yet accepted to work on)
• ~“mktg-status::wip” (issues that have been accepted by a member of our team, added to a milestone)
• ~“mktg-status::review” (issues where the social media team have delivered “proofs” of posts to stakeholder for approval)
• ~“mktg-status::scheduled” (issues where the social media posts are approved, added to Sprout calendar, and the issue can be closed)
• ~“mktg-status::blocked” (when the social team is waiting on additional information, assets, or other needs and cannot yet complete the work in the issues)

Optional Labels

More on optional labels will be available soon.

Giveaways on Social Media

Giveaways Process

Day of giveaway

After the Giveaway

Sprout Social

Tagging

Tag a post after its been published

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:

1. head to the reports tab
2. select the cross-network reports category
3. choose the post performance report
4. use channel and publishing date filters to find the posts you’re looking for
5. click the outline of the tag icon 🏷, select the tag(s) for the post; the tag icon will now be blue to indicate there are tags added

Other administrative items

LinkedIn Events

Our 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.

LinkedIn Event Speaker Line Up

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.

Required elements for a LinkedIn Event page

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.

• Event name (up to 75 characters)
• Start/End date and time in a specific timezone (LinkedIn will convert to the users local timezone when it appears to them)
• A description of the event - answering the who, what, where, when, and why of the event (up to 5,000 characters)
• Registration link for users (remember to shorten the link with a bit.ly and consider adding UTM tracking specific to LinkedIn Event page for tracking)

Optional items for LinkedIn Events

• Unique-to-event profile image (1:1 ratio)
• Unique-to-event banner image (4:1 ratio or 1584 x 296)

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.

Non-social team admin access to select social channels

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.

Field Marketing team access to LinkedIn events feature

🔗 View the field marketing LinkedIn admin for events quick training video

View the field marketing LinkedIn admin for events quick training video on private Unfiltered channel

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.

Social channel colors

Please use the following hex colors to represent the channels in reports, in charts, or when calling it out in plain text.

• Facebook - #1778F2
• Insta - #8A3AB9
• LI - #0E76A8
• Twitter - #1DA1F2

Social Media Profile assets

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.

User Generated Content confirmation

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]

View page source - Edit this page - please contribute.