Commit de23a968 authored by Wil Spillane's avatar Wil Spillane

Adding Admin topics to admin handbook page

parent 783d741e
Pipeline #148410450 canceled with stages
in 2 minutes and 54 seconds
layout: handbook-page-toc
title: "Social Media Administration"
description: Workflows, Templates, and more for GitLab Team Members
twitter_image: "/images/opengraph/social-handbook.png"
twitter_image_alt: "GitLab's Social Media Handbook branded image"
twitter_site: "@gitlab"
twitter_creator: "@gitlab"
## On this page
......@@ -9,6 +14,157 @@ title: "Social Media Administration"
{:toc .hidden-md .hidden-lg}
## Uses
## Welcome to the Social Marketing Administration Handbook Page! Please use the table of contents on the right side of the page to find the topic you need assistance with. 👉
**This page is the single source of truth for all administrative tasks, templates, and processes focused on GitLab brand social channels. If your question is "how?", the answer will be here.**
This page is to be used for all things social media admin.
\ No newline at end of file
## Requesting Social Promotion <a name="requesting social promotion"></a>
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 social + [your focus or campaign] epic
If you are requesting coverage for something that is:
* part of an integrated campaign
* has more than one link/asset/audience/or end-user objective
* will have more than one "deliverable"
Please open a new epic in the Corporate Marketing project. This specific epic will be a place to outline strategies, discuss MVCs and changes, and provide reporting updates. Then, open a social request issue for each specific ask. E.g., for integrated marketing campaigns, there are several collateral (a blog, a webcast, and a gated asset landing page). It would be best to open a "child epic" for Social + Campaign Name and create a separate issue for each piece of collateral.
This will allow us all to better understand due dates, milestones, and to close issues promptly when the specific request is fulfilled.
If you're not sure if you need an epic or just an issue, feel free to ask in the #social_media Slack channel.
### Open a new issue to request social coverage
Once you've opened the epic (if the ask is a part of the list above)
- Head to the [corporate marketing project]( and create a new issue.
- Select the appropriate issue template:
- **social-event-request** for coverage of events (tradeshows, etc.)
- **social-team-advocacy** when the project calls for GitLab Team Members to support our campaign efforts on their personal social channels
- **social-general-request** for every other request
- Fill out as much information as you can above the first line in the issue.
### Please remember...
- For an anything to get promoted on social, **there must be a dedicated social issue**.
- If the need is urgent, send a message to the `#social_media` Slack Channel.
- If you have already requested or received images for social (paid) ads, please mark that issue as related in the organic social request issue.
- If you have not already requested or received images: Shortly after you open your social issue, the social team will assess whether there are existing assets we can use on social, or if new ones are needed. They will then request new images from the design team, or remove them from the issue. It is at the design teams' discretion whether they have time to create the images, particularly if you open your issue within ~ 1 week of the need to publish.
- 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.
## 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 external posts should contain a UTM parameter, please see [details in the Digital Marketing handbook](/handbook/marketing/revenue-marketing/digital-marketing-programs/digital-marketing-management/#url-tagging).
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.
## 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 <a name="giveaways"></a>
We use giveaways to encourage and thank our community for participating in marketing events such as surveys, user-generate-content campaigns, social programs, and more.
If you're looking for steps on how to create and process swag for a giveaway, please use the [GitLab Giveaway Guide](/handbook/marketing/community-relations/community-advocacy/workflows/merchandise-handling/giveaways/)
### Giveaways Process <a name="giveawaysprocess"></a>
1. Create an issue and tag the Social Marketing Manager to determine the
rules of engagement and the Corporate Events Manager for prizes.
2. Create and publish an [Official Sweepstakes Rules page](#officialrules)
1. Winners must sign an Affidavit of Eligibility & Liability, Indemnity, and Publicity Release. Use the "Affidavit of Eligibility - Sweepstakes" template found on the google drive.
2. Announce the winners
#### Creating the Campaign
- Set a launch date
- Ask for social image(s) with text (if organic posts only) explaining the offer/ask
- Set an initial deadline for submissions, so you can have multiple pushes at interval & ramp up energy
- Finalize the delivery method: form vs. tweets vs. retweets, depending on the goals of the campaign
- Pros of a form: Neat, uniform, easy for us to keep track of, no downsides of low engagement (i.e., responses not visible)
- Pros of asking for submissions via Twitter: we could more easily RT cool responses, get more out of a hashtag, etc.
- Pros of asking for RTs in exchange for swag: very little backend to do on social afterwards, except to announce the winners of swag
- Finalize the ask, making sure it's extremely clear what you want to happen (`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`)
- Make sure the ask can be intuitively communicated via whichever delivery method you're using, i.e., the tweet doesn't need to explain everything if you're pointing to a form or blog post. If you're not pointing to anything, make sure the tweet plus possible image text must make sense by themselves. Use threads for more space!
#### Pre-launch
- Finalize the timeline for when the reminders/follow-ups will go out, add to social schedule and leave some space around them to RT/engage with responses
- Finalize copy for all pushes
- If swag is involved, create a google sheet with swag codes from the Event Marketing Manager
- Finalize hashtag
- Ask community advocates to review all copy (tweets, form, blog post) and adjust according to their suggestions
- Make sure the community advocates are aware of the campaign timeline/day-of
- Designate a social point person to be "on duty" for the day-of and one person who can serve as backup
- Let the broader GitLab team know that the social campaign is upcoming and ask for their support
#### Day of giveaway
- If you have entries for the giveaway in a spreadsheet, use []( to generate a random number. Match the number to the corresponding row in your spreadsheet to identify the winner. **Never enter email addresses or personal information of participants into a third-party site or system we do not control.**
- Try to schedule first push or ask a team member to tweet the first announcement early (ex: around 4 am PT) to try to have some overlap with all our timezones
- If you're asking for RTs in exchange for swag, make sure there's a clearly communicated cut-off to indicate that the giveaway will not stretch into perpetuity. One day-long is probably the longest you want a giveaway to stretch, or you can limit to number of items.
- Plan to engage live with people
- If your promise was to give away one hoodie per 25 RTs, do it promptly after that milestone is crossed. It adds to the excitement and will get more people involved
- Announce each giveaway and use handles whenever possible, tell them to check their DMs
- DM the swag codes or whatever the item is
- In your copy, directly address the person/people like you are chatting with them irl
- RT and use gifs with abandon but also judgment
#### After the Giveaway
- Thank everyone promptly, internal & external
- Write in the logistics issue of any snags that came up or anything that could've gone better
- Amend hb as necessary for next time
### How to Create an Official Sweepstakes Rules Page <a name="officialrules"></a>
1. Create a new directory in `/source/community/sweepstakes` in the www-gitlab-com project. Name the directory the same as the giveaway `/source/community/sweepstakes/name-of-giveaway`
2. Add an file to the `/name-of-giveaway/` folder
3. Add the content of [this template]( to the `` file.
4. Replace all bold text with relevant information.
5. Create merge request and publish.
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment