Add change_dap_land_default_credits experiment

Roy Liurequested to merge
glforge/619294-experiment-implementation-change-default-credits into master

Summary

Adds change_dap_land_default_credits, a GLEX growth experiment behind a type: experiment feature flag (default_enabled: false), gated on the namespace.

The Customers Portal defaults the DAP Land SKU purchase-credits quantity to 5, and we suspect that default is causing underpurchasing. This experiment tests whether pre-filling 25 credits — closer to actual trial-account usage — reduces underpurchasing without hurting conversion. See the experiment issue: https://gitlab.com/gitlab-org/gitlab/-/issues/619294

How it works

The experiment is assigned per-namespace when the group billing page renders. In billing_plans_helper.rb, the candidate variant appends quantity=25 to the purchase-credits URL passed to the frontend, so the Customers Portal pre-fills 25 credits on load; control leaves the URL unchanged and the portal falls back to its own default of 5.

Tracking

Three funnel events, all carrying the experiment's gitlab_experiment context:

  • :assignment — published automatically when the experiment runs on the billing page render path.
  • click_purchase_credits_dap_land_sku — fired client-side from dap_monthly_credit_card.vue when the user clicks the purchase CTA.
  • finish_purchase_credits_dap_land_sku — fired server-side from provision_service.rb after a successful gitlab_credits provisioning, scoped with only_assigned: true so namespaces never exposed to the billing page aren't segmented into the funnel. Provisioning updates and deprovisions also flow through this path, so conversion analysis should count distinct assigned namespaces rather than raw event counts.

All experiment code and specs live under ee/; specs cover both variants across the helper, experiment, provision service, and Vue component.

Validation steps

  1. Run GDK with SaaS simulation enabled by setting GITLAB_SIMULATE_SAAS=1.
  2. Use a top-level group on a free plan or an active trial, since paid non-trial groups render a different billing view without this card.
  3. In the rails console, toggle the variant with Feature.enable(:change_dap_land_default_credits) for candidate or Feature.disable(:change_dap_land_default_credits) for control.
  4. Visit the group's billing page at /groups/<group-path>/-/billings.
  5. On the GitLab Credits card, inspect the Purchase credits CTA link (data-testid="dap-monthly-credit-card-cta-button"): the candidate variant's href contains quantity=25, while the control variant's href has no quantity param.
  6. Optionally verify via Snowplow Micro that rendering the page publishes the :assignment event and clicking the CTA fires click_purchase_credits_dap_land_sku, both carrying the gitlab_experiment context with the variant.
  7. Note that the server-side finish_purchase_credits_dap_land_sku event fires when CustomersDot provisions the gitlab_credits add-on; this isn't easily exercised in a plain GDK, and is instead covered by the provision service spec.

What are the relevant issue numbers?

Closes https://gitlab.com/gitlab-org/gitlab/-/issues/619294

Edited by Roy Liu

Merge request reports