RALPH LAUREN · GLOBAL DIGITAL PRODUCT · 2023–2025
Private Store
Building a controlled digital outlet.
Connecting customer access, commercial rules and sales attribution.
As global product lead, I took ownership of Ralph Lauren’s Private Store enhancement when the initiative stalled, aligned business and technology teams, and moved the program through delivery. The tiered experience functionality launched, enabling customer-group-based shopping experiences within a controlled digital outlet. The initial MVP focused on UK/EMEA access and reporting, supporting excess-inventory distribution while protecting brand equity.
I led product scope, business-rule alignment, integration requirements and investment planning across customer eligibility, account access and transaction reporting. The work connected in-store registration and Zeta customer data to Salesforce Commerce Cloud, then carried purchase classification through order management and downstream reporting.
Global product lead · MVP scope, customer eligibility, tiered experiences, integration requirements, investment planning, vendor coordination, UAT and release readiness.
$1M–$5M
Commercial target for the Private Store enhancement.
$97.7K
A $97,702 proposal covering SFCC development, QA and delivery leadership.
17 contributors
Aligned 12 staffed functions across the Private Store program.
Inside the Private Store shopping experience
Private Store offered a controlled route for excess inventory while protecting brand equity. Its customer-group objectives connected outlet acquisition with retention, reactivation and trade-up or trade-across into the wider Ralph Lauren assortment.
Private Store navigation
Last Chance · Promotional shopping

Luxury Shop · Curated assortment

Shop All · Additional shopping example
Shop All · Additional shopping example

Earlier storefront reference
- The existing experience
- Customers registered through in-store email capture, then received source-code links by email or SMS. The existing journey could take about three weeks.
- The product opportunity
- Make recurring access recognizable through an eligible customer’s account, while keeping the channel’s customer rules and sales classification explicit.
From outlet signup to account-based access
An eligible outlet signup or purchase—or qualifying prior Private Store activity—would be recognized by email. Existing customers sign in; new customers create an account. Private Store then appears in navigation.
1. Sign in or create an account
2. Enter Private Store through navigation
July 2024 · Original account-access journey
- Who qualifies
- The July design recognizes outlet purchases, Polo Live signups and qualifying prior Private Store activity, including customers covered by the RAPP hotfix. Recency windows remained a business-policy decision.
- An acquisition exception
- Limited acquisition campaigns retain source-code entry. The scoped proposal requires sign-in or registration at checkout for those campaigns, including full-price-only baskets.
Access timing · Process and planning
- Existing link journey
- ~3 weeks
Process described in prior journey material.
- Early aspiration
- 24 hours
Access planning target after email capture.
- Later planning window
- 2–3 days
Signup to customer-group membership.
Turn eligibility data into storefront access
Eligibility is a data responsibility; gated access is a commerce responsibility. I aligned the handoff so the customer’s entitlement could govern the account experience.
- Zeta / GCD · Eligibility
- Own customer eligibility and provide a daily CSV containing email and an entitlement flag. A one-time migration is limited to active eligible customers, with CRM defining the active population.
- SFCC · Account and access
- Match email at registration or sign-in. A profile attribute and dynamic customer-group membership govern gated navigation and access.
- Customer communications · Entry
- An eligibility update and the communication explaining how to enter are different handoffs. They need aligned customer rules and release timing.
Systems requirements and validation cases
Changed email addresses, duplicate matches and delayed entitlement feeds were explicit requirements and validation cases. The access contract needed to address grant and revocation behavior consistently with customer-group membership.
The delivery dependencies were agreed Zeta and Ralph Lauren architecture business rules, a sample entitlement CSV, and a working feed with customer email and entitlement flag. These defined the inputs needed for commerce validation and UAT.
Keep customer classification and access aligned
Marketing business-unit assignment is not the same thing as Private Store entitlement. The required hierarchy accounts for how subsequent channel activity changes customer classification.
- PFS, RLE and RLS
- PFS identifies the Private Store/outlet customer group, RLE ecommerce and RLS retail. Existing rules can move a shopper to the RLE business unit while a separate Rapp data-container flag preserves Private Store status.
- Basket and customer are different decisions
- A Private Store purchase can retain PFS classification even when it includes full-price items. Later channel activity must keep customer classification, commerce behavior and communication aligned; a business-unit change does not inherently mean access is revoked.
Launched tiered experiences
The tiered experience functionality launched, giving Private Store a customer-group framework for differentiated shopping experiences. The design connected eligibility and reassignment rules with Lux and Premium experience tiers.
Customer-group rules connected purchase activity and recency with eligibility, reassignment and access across customer data, commerce and communications.
Know what sold, where it sold, and what came back
Reporting needed two distinct granularities: item-level attribution for commerce reporting and order-header classification for customer data. Mixed baskets made that separation essential.
- Order line · OMS → BI
- Capture both product assortment usage—full-price, Private Store or price establishment—and purchase environment. OMS stores the line-level attributes for BI and downstream reporting, including the Snowflake dependency.
- Order header · MBS → Zeta
- MBS feed updates carry full-price/RLE, PFS or mixed-basket classification to Zeta. This order-header view is different from BI’s item-level detail.
- Keep historical attribution stable
- Returns retain classification from the original demand order. Later product changes must not rewrite what was sold. Category, search, recommendation and wishlist entry paths need consistent classification and fallback rules.
Release sequencing and reporting scope
The intended reporting coverage included demand, fulfillment, net sales and gross margin. Attribution for products exposed in both environments remained a discovery item.
Reporting-feed timing was a release dependency: launching access first would require capturing interim data for later retransmission. I connected access and reporting requirements to make that sequencing decision explicit.
Analytics tagging and report creation were excluded from the $97,702 implementation estimate. A general historical load and Enterprise Planning inventory requirements were outside the reporting scope.
Restore a delivery path and make the scope executable
As global product lead, I restored momentum to the stalled PFS Gated program, aligned the cross-functional teams and led the product scope through delivery. Private Store launched its tiered experience functionality, connecting customer-group eligibility with differentiated shopping experiences.
- Focused MVP
- Keep UK/EMEA in scope and NA/APAC out. Retain existing Private Store pages, signup and notifications while addressing account access and feed changes.
- Cross-functional coordination
- The journey roster brought together 17 named participants across 12 staffed functions, with architecture, development and QA identified as additional delivery workstreams.
- Connected readiness
- Agree Zeta and RL architecture business rules, obtain the sample entitlement CSV and working feed, then connect release timing with SIT/UAT and customer communications.
Approximately 15 weeks · Planned implementation
- Requirements & technical design
- Development / testing
- SIT / UAT
- Go-live
Implementation estimate · $97,702
| Role | Location | Allocation | Estimate |
|---|---|---|---|
| Sr SFCC developer | Offshore | 100% | $28,408 |
| SFCC developer | Offshore | 100% | $15,120 |
| QA lead | Offshore | 100% | $19,008 |
| Product / project manager | Offshore | 50% | $9,216 |
| Local technical lead | Local | 25% | $25,950 |
| Total estimate | $97,702 | ||
Problem & objectives
Project remit
- Scope
- December 2023–May 2025. UK/EMEA-focused MVP with Zeta, Salesforce Commerce Cloud and Snowflake dependencies, plus customer communications and downstream order/reporting feeds. NA and APAC were outside the MVP scope.
- Status
- Launched tiered Private Store functionality, supported by customer-group eligibility and differentiated shopping experiences.
The business needed a controlled outlet channel that protected brand equity and connected customer access with clear sales attribution.
Replace a slow link-based access journey
The customer-group objectives connected excess-inventory distribution with outlet customer acquisition, retention, reactivation and trade-up or trade-across. Account-based access needed to support that commercial purpose without losing control of who entered the gated environment.
Customers registered through in-store email capture, then received source-code links by email or SMS, typically after about three weeks. Recurring access through an eligible Ralph Lauren account addressed recognition, navigation and activation together.
Keep qualification and purchase classification consistent
A customer could qualify through a store sign-up, purchase full-price and Private Store products in the same basket, or later return an item. The implementation needed to preserve what qualified the customer and how each purchase should be reported across the connected systems.
The business rules also had to address customer classification: a PFS customer shopping on RLE could move into the RLE business unit in Zeta while a separate Rapp data-container flag preserved Private Store status. The required hierarchy had to account for that distinction.
Decisions & trade-offs
I sequenced focused UK/EMEA eligibility, account access and reporting scope with the broader customer-group capability, which launched as tiered experiences.
Define an achievable regional MVP
I kept the initial scope focused on the UK and EMEA and aligned implementation around customer eligibility, account access and reporting. I led scope tradeoffs, estimating, vendor coordination and budget planning, securing approval for an implementation plan spanning approximately 15 weeks.
NA and APAC were outside the initial MVP scope. The plan retained the existing Private Store pages, sign-up and notification processes, while adding the access and feed requirements needed for account-based entry.
Set access timing expectations
Early planning targeted access within 24 hours of email capture. The implementation plan allowed a two-to-three-day interval between sign-up and customer-group membership.
For the account journey, an eligible customer’s sign-in or registration should reveal Private Store in navigation. The MVP proposal retained limited acquisition source codes as a separate exception, with account creation or sign-in required at checkout even when the basket contained full-price items.
Sequence access and tiered experiences
I sequenced the focused UK/EMEA access scope with the broader customer-group capability that followed and launched as tiered experiences. The design connected eligibility and reassignment rules with Lux and Premium experiences, keeping the initial MVP distinct from the broader capability.
Customer-group rules connected purchase activity and recency with eligibility, reassignment and access across customer data, commerce and communications.
Experience & systems
The access feed, account matching and reporting attributes needed distinct contracts and consistent business rules.
Translate eligibility into account access
The entitlement contract assigned eligibility to Zeta/GCD and specified a daily CSV with email address and entitlement flag. A one-time migration covered active eligible customers only, with CRM defining active. SFCC used email matching, a profile attribute and dynamic customer-group membership to translate that data into account access.
On account creation, the requirement was to recognize eligible sign-ups by email address and add the account to the appropriate customer group. On sign-in, membership controlled gated navigation. I also defined access grant and revocation and the edge cases that could interrupt them: changed emails, duplicate matches and delayed feeds.
- Daily feed for new and updated qualification data.
- One-time migration limited to active customers.
- Email matching when a customer registers or signs in.
- Dynamic customer-group membership and corresponding access behavior.
- Explicit requirements for changed emails, duplicate matches and delayed feeds.
Distinguish item-level reporting from order-level classification
Mixed baskets required an explicit distinction between order-level and order-line classification. I led requirements to separate full-price and Private Store purchases and preserve the original classification through returns, supporting consistent downstream reporting in Snowflake.
The reporting requirements called for two item-order-level attributes: the product’s assortment usage flag and the environment from which it was sold. They distinguished full-price, Private Store and price-establishment assortment states. The transaction association had to record the product’s classification when sold, and a return had to retain the value from the original demand order.
Downstream consumers needed different levels of detail. BI required item-level product and environment attributes, stored in OMS and published into reporting. Zeta used order-header classification to distinguish PFS, RLE and mixed baskets. The plan called for OMS and MBS feed updates to carry the required data.
- Preserve both product-assortment classification and purchase environment.
- Support order-header full-price, Private Store and mixed-basket reporting alongside item-level detail.
- Keep the original demand-order values on returns.
- Define classification behavior for products reached from parent categories, search, recommendations and wishlists, including fallback behavior.
Align access with activation and measurement
I sequenced dependencies across Zeta, SFCC, Snowflake and customer communications so the eligibility feed, commerce behavior and reporting could be delivered coherently. Account-creation and acquisition events also needed to retain the appropriate business-unit and Private Store-access flags used for marketing.
The reporting work included marketing entry points and gated-environment visits and conversion. Measurement design and attribution for products exposed in both environments remained open for further discovery. Analytics tagging and report creation were outside the implementation estimate; a historical load and Enterprise Planning inventory requirements were outside the reporting scope.
Delivery & validation
Delivery depended on working entitlement data, agreed classification rules and coordinated release timing across commerce and reporting.
Sequence the work around real dependencies
The approximately 15-week proposal placed requirements and technical design ahead of development, SIT/UAT and go-live. Its explicit dependencies were agreed business rules with Zeta and Ralph Lauren architecture, a sample entitlement CSV, and then a working feed containing the customer email and entitlement flag.
As global product lead, I led scope through delivery and coordinated UAT, release readiness and cross-functional work. The journey roster brought together 17 named participants across 12 staffed functions, with architecture, development and QA identified as additional delivery workstreams.
Prevent a gap between access and reporting releases
Release planning had to address a sequencing risk: if gated access launched before its outbound reporting feeds, the intervening demand, fulfillment and traffic data would need to be captured for later retransmission. Delivering the feeds concurrently would avoid that gap.
The release sequence and any retransmission requirement remained delivery dependencies to resolve. A general historical load was outside the reporting scope.
Make investment and scope executable
The implementation proposal estimated $97,702 across offshore senior SFCC development ($28,408), SFCC development ($15,120), QA leadership ($19,008), product/project management at 50% allocation ($9,216), and a local technical lead at 25% allocation ($25,950). The other offshore roles were allocated at 100%.
The old kickoff R24.02/R24.03 schedule was proposed. Planning connected requirements, feed readiness, UAT and outbound reporting dependencies rather than establishing an actual production date.
Outcomes & learning
I restored momentum to the stalled program and led product scope through delivery; tiered Private Store functionality launched with customer-group-based shopping experiences.
Launched capability and cross-functional delivery
As global product lead, I took ownership of the stalled PFS Gated initiative, aligned the cross-functional teams and moved product scope through delivery. The tiered experience functionality launched, giving Private Store a customer-group framework for differentiated shopping experiences. The work established a focused UK/EMEA MVP and aligned integration requirements across customer eligibility, business-unit classification, commerce behavior and downstream reporting.
The commercial case carried a $1M–$5M annual EMEA revenue target; the implementation proposal was approximately 15 weeks at an estimated $97,702.
The lesson was to treat access, classification and communication as related but distinct product decisions. Sequencing the focused MVP and broader tiered customer-group capability kept the delivery path executable.
