Discover

The bet.

Market position, competitive landscape, and phased delivery model. Every claim in this page traces to a source file in research/competitive/synthesis.md.

The use case — representative scenario

A Sony merchandise manager creates an employee discount.

The promo code goes out to the employee Slack. Someone posts it on a deal-sharing site. Finance flags a margin spike. Post-mortem requires a technical control — not a policy.

The fix is obvious: restrict the promotion to customers whose email address ends in @sony.com. BC's promotions engine has no mechanism for this. The customer object at evaluation time is { ID: CustomerID, GroupID: GroupID } — email is not there.

The current workaround

  1. 1. Manually add every employee to a "Staff" customer group
  2. 2. Target the promotion at that group
  3. 3. New hires require a CS ticket to add; leavers are rarely removed
  4. 4. A shared coupon code still bypasses the group check entirely

Market position

source: synthesis.md ↗
Platform Email domain native? Custom attributes? No-code config?
SAP Commerce Cloud (extension required) Yes (via RAO extension) Yes (group-based only)
Shopify Yes (all paid plans, signed-in only) Yes (metafields as segment filters) Yes
SFCC (email type blocked) Limited (type restrictions) Partial
Adobe Commerce Yes (paid tier, signed-in only) Yes (deepest no-code path) Yes
WooCommerce Yes (paid plugin) (no native path) Partial
BigCommerce (current)

BC row: customer-attribute promotion targeting is not available on any plan. Footnote: Shopify ships email domain targeting on all paid plans. Adobe Commerce ships it on paid (non-open-source) tiers. BC currently meets none of the three market-minimum criteria.*

*Market minimum criteria: (1) runtime-evaluated customer targeting, (2) email domain as a native condition, (3) no-code CP authoring. Source →

Differentiator

Guest checkout targeting is a BC-native advantage

BC evaluates billing_address.email for unauthenticated sessions at checkout step 4 — the email is in the cart record before promotions evaluate. Shopify's email targeting is signed-in only. Adobe Commerce's is too. A B2B buyer who always checks out as a guest but enters a corporate email address would qualify for an employee promotion on BC — and not on Shopify. This is a Phase 2 differentiation point, not a Phase 1 blocker.

Phased delivery — designed sequence, not scope hedge

The phase boundary has a specific architectural reason: email is already in the cart record at checkout step 4 (zero new service calls); custom fields require a gRPC call to customers-scala on the checkout critical path (5–15ms). Phase 1 ships the Sony use case immediately. Phase 2 ships platform extensibility when the Go service extraction reaches the customer-attribute evaluation path.

Phase 1

Email domain targeting

@sony.com → employee-only promotions. Email is already in the cart record (billing_address.email). Zero new service calls. PHP typed conditions DSL extension in bigcommerce/bigcommerce.

Dependency: none beyond standard bcapp extension pattern

Phase 2

Company name + CEL engine

PromotionEvaluationContext struct in Go service. CEL expression evaluation path. Company name via one Redis-cached gRPC call (~2–5ms). Guest checkout targeting via billing_address.email.

Dependency: Go service extraction milestone

Phase 3

Custom fields + order history

Customer custom fields (formfieldvalues, customers-scala gRPC). Order count and lifetime value signals. Materialized customer snapshot in Redis to avoid checkout-critical-path latency.

Dependency: Phase 2 + customer snapshot infrastructure

Who this is for