Add Offline checkbox in Salesforce to supplement product usage data

Glossary / Key Terms

  • Offline Environments
  • Air Gap - network security measure employed to ensure a secure local computer network is physically isolated from unsecured networks, including the public Internet (all intranet, no internet)
  • Network Secrity Policy - document that defines network security rules and requirements for a company or organization, and outlines how these policies are to be implemented & enforced
  • Usage Ping - feature that gathers and sends anonymous GitLab product usage data (opt-out, enabled by default)
  • Benefits of Usage Ping
  • Seat Link - a feature of GitLab used for Licensed user reconciliation

Problem Statement

What is the problem?

Self-managed customers required to host GitLab in an offline environment will have Usage Ping and Seat Link blocked at the network layer even if they are enabled in the GitLab application settings.

Why is this a problem?

Self-managed customers operating GitLab inside an offline environment account for up a significant portion of our ARR. However, air gaps block valuable usage data that we use to prioritize customer results, identify underutilized features, and determine what will provide the most value for our users.

Usage ping data from customers required to run GitLab in an air gap will not accurately reflect product usage for these customers, as the usage ping payload most likely came from a GitLab testing/staging instance installed outside of the air gap.

Proposal

Create an Offline checkbox in Salesforce that Sales and Support can use to indicate when we identity customers who are running their production GitLab instance in an environment without access to the public Internet.

The Offline checkbox in Salesforce should only be used only if both of the following statements are true:

a) the customer is operating GitLab in an offline environment as defined here

AND

b) the customer is required to operate GitLab in an offline environment for compliance with internal security policies

Proposed Process

The process will differ depending on who is getting signal that the customer is running GitLab in an Offline Environment - Sales, or Support.

Sales will be the only ones who are to check the "Offline" checkbox if both of the criteria in the proposal are met.

If Sales is certain that the customer has an air gap or offline environment requirement as part of the network security policy, they check the checkbox.

Support will reach out to Sales if we find or are informed that the customer has an offline environment or air gap requirement.

If Sales isn't sure if the offline environment is required for compliance with an internal policy, Sales would reach out to the customer for clarification.

"Say why, not just what"

The reason "why" for I'm proposing this is to help:

  1. Quantify the percentage of customers operating GitLab in environments where automated submission of usage ping/seat link data is a technical impossibility.
  2. Allow accurate measurements of customers who've opted-out or disabled usage ping versus those who have it enabled but ultimately blocked by network security policies. (Self-managed customers with no usage ping/seat link payload either opted-out and turned the settings off in application, or its blocked at the network layer. Knowing which customers opt-out, and which customers have usage ping/seat link on, but blocked at network layer is valuable data)
  3. Supplement usage ping and product usage data with an estimate of ARR coming from self-managed customers unable to provide usage ping/seat link data.
  4. Evaluate priority and customer results of developing product features and capabilities specifically geared towards customers operating GitLab in "offline" environments.
  5. Indicate which customers will be unable to use Seat Link for renewals and true-ups as a result of network security policies blocking seat link.

Context and Examples

Examples of "Check the air gap checkbox" use cases

  • Customer communicates to Support or Sales that they're required to host GitLab in an offline environment without internet access
  • Sales, TAMs, SAs, Customer Success knows that a customer's network security policy specifically prohibits access to "unsecured networks (the public internet) and/or outbound "phone home" traffic (especially relevant to PubSec & Financial Sector customers)
  • Support knows from experience that customer X can't export logs, share configuration files, screenshare, or send screenshots because their GitLab runs in an air gap, with no internet connectivity

Example why this is a problem

In the past year, we've responded to demand from large customers by ensuring that Ultimate-only Secure-stage features can work in "offline" environments. Having GitLab features work "offline" (without direct internet connectivity) is a hard requirement for any customer with an air gap in their network security policy.

The initial request to make SAST available offline came from a large PubSec customer who was considering an upgrade from Premium to Ultimate, but whose air gap requirement resulted in all Secure CI jobs failing at the initial docker pull registry.gitlab.com step.

In the past 7-8 months, the Secure team has worked to ensure all of the Secure Stage features can work "offline", without direct internet connectivity.

Customers operating GitLab in environments where Offline functionality is a requirement, usage of "offline" features will not appear in the product usage data we receive and analyze.

As a result, I expect MAU and Secure stage usage data for using Secure-stage features "offline" will be unrealistically low simply because we can't get usage ping data from "offline" environments like air gaps.

Actionable next steps

  • find appropriate issue tracker and move this issue to it
  • ping sales ops for requirements/process to add this checkbox in Salesforce
  • work with Sales to come up with a process to check this checkbox
  • add handbook entry on air gap checkbox with criteria and workflow for checking air gap checkbox
  • add additional to-do entries after consulting Sales and sales-ops here

Here's the issue I promised @kevinchasse @mterhar @JamesRLopes @jcolyer @rparker2 @sytses. What do you think?

Edited by Greg Myers