Email database management is a core responsibility for MktgOps. Ensuring GitLab is following email best practices, in compliance with Global spam laws and overall health of active database are all priorities.
Email creation and email nurture programs are managed by the Campaigns Team. To learn more about GitLab email communication or request an email, please see the Emails/Nurture Handbook in the demand generation section of the handbook.
Please visit the legal page to view all of the Marketing Rules and Consent Language.
The Mural below shows the opt-in and opt-out/unsubscribe workflows for all forms, list imports and individual subscriptions.
At GitLab, we strive to communicate with people in a way that is beneficial to them. We always include the unsubscribe link in our communications, and we respect the unsubscribe list. In addition to the unsubscribe button at the bottom of all of our emails, we have available our Email Subscription Center, where people can control their email communication preferences.
Each form will have the appropriate opt-in language specifid. However, to check you may visit here.
We have a Marketo enforced limit on how many emails a single address can recieve per day and week. The limits are 1/day and 3/week. Once a person has hit that limit, they are supressed from email groups until they fall back under the threshold, unless the email is marked as
operational. However, emails marked as
operational will still be sent.
The email limits are not set in campaign templates, however, if your email is set to send to more than 20,000 people, you must include a filter for
Not Sent Email in last 2 Days.
If a person asks a team member to remove them from email marketing from GitLab, the team member can take a few different steps stated below. If a person unsubscribes, they may still receive operational emails related to their account.
email opt outbox, which will then update the unsubscribe checkbox in Marketo and Outreach.
Certain emails can bypass unsubscribe and invalid emails by being marked as
operational. Examples include critical system alerts, account updates (policy updates, etc.), event reminders with necessary link to attend event, and auto-responders for post event recording and slides emails. Please follow this decision tree for auto-responder emails to help determine whether or not your email fits the operational standards. If they do not, you must include the proper email compliance filters in order to send the email, and also uncheck the operational check box on the email.
Emails that contain mostly marketing or promotional content like newsletters, event invites and sales emails are not considered
operational. Only MktgOps and certain MCMs have access to this feature in Marketo. If you have any questions on whether or not your email is operational, contact MktgOps, who will bring in Legal for a final review. When in doubt, ask!
These are transactional emails, almost always to our user base, that provide very selective needed information. This is an
operational email that overrides the unsubscribe and would not need to comply with marketing email opt-out. Usage example: GitLab Hosted billing change, Release update 9.0.0 changes, GitLab Page change and Old CI Runner clients.
It is very important to have Engineering and/or Product team (whoever is requesting this type of email) help us narrow these announcements to the people that actually should be warned or notified, so we are communicating to a very specific focused list. The email platform the send will come from will be determined by a few different factors, but mainly list size. If you need to request an email like this, use this the
incident_communications template and reference this section.
Security Releases Sent on an as needed basis containing important information about any security patches, identified vulnerabilities, etc. related to the GitLab platform. These emails are purely text based and again are transactional in nature. Users can subscribe to security notices on the GitLab Contact us page.
Webcasts Invitation and/or notification emails sent about future webcasts.
Live Events Invitation emails to attend a live event, meet-up, or in-person training. These emails are sent to a geo-locational subset of the overall segment. This type of email is also used when we are attending a conference and want to make people aware of any booth or event we may be holding and/or sponsoring.
While a partner is in contact with a lead or contact, GitLab should stop emailing the prospect so that the partner can follow up. Once the partner rejects or if GitLab recalls the lead, the lead can then be emailed again by GitLab (assuming we have consent). As of 2021-12-28 we have not yet set up a process for a lead to be returned to GitLab and become emailable.
The workflows in Marketo are set up and are reflected here. If a lead or contact has a
Prospect Share Status of
Sending to Partner,
Pending, Marketo will suppress them from all GitLab marketing sends (operational emails will still send).
If a lead comes in via Partners from MDF or Trial campaigns, they are marked as
Marketing Suspended in Marketo with a reason of
Partner Lead, and will be un-emailable until that suspension flag is lifted.
If a person opts-out of GitLab email, it does not opt them our from Partner communication, and vice versa. It is the responsibility of the partner to manage their email lists.