Objective
Offer a high trust pricing and discounts experience for users
Problem
Currently users see the listing price change to a higher price when a discount is provided. This leads to poor trust for users especially with our positioning as a low price platform.
Context
We operate on a mark up model i.e final listing price= Seller input price + shipping User specific and platform discounts reduce the listing price to the end consumer price When any discount is applied, we currently additionally inflate the BAU listing price and showcase this as the strike-through price. Reasons for this are: Seller requirement: Where supplier funded offers exist, seller discount inputs are shared as a ‘%’ discount on the input price. Sellers expected the same discount ‘%’ to be visible on the marked up price/fully loaded price (input price + shipping). Since the actual absolute discount is fixed, the strike through price was additionally marked up to showcase same discount %. Tech effort: Even for platform funded offers where there is no input side need (ad outlined above), building an infrastructure to index different prices across users for each catalogue was high effort, complex and costly due to which maintaining a single discount % with varying strikethrough price was a preferred approach E.g - 100 is listing price, delivery fee for 2 location 40 and 60.
So total price for location A - 140 and for B- 160
During sale On giving 10 % discount on listing price new listing price will be 100 - 10 = 90Rs
Since delivery fee is constant new price A- 130, B- 150
For A- price was 140 -> 130 which is 7.14% discount
For B- price was 160 -> 150 which is 6.25% discount
With our current system we can't have multiple discount, thus we artificially increase the price to show a common discount across all.
Taking the above example, say when we are giving 10% discount
For A- price is 130 -> We will show 10% more price 130 + 14 = 144 Rs
For B- price is 150 -> We will show 10% more price 150 + 16 = 166 Rs
Note: Here we are not solving on different price on different location, the solution is with respect to change of item price during sale and non sale time. Implications
User trust: The above decisions negatively impact user trust with feedback from users where they notice that the true discount is much lesser than the claimed discount since the strike through price has been inflated. Downstream system failures: With user specific discounts, the end customer price has become dynamic. Since we lack the infra to support such a variable, we only index the seller input price + shipping (without zonal discounts) as the fixed price for every catalogue irrespective of discounts applied. Downstream systems which consumer such variables to create user experiences such as CLP and sort and filter are unable to capture the actual price the user will see and thereby have a broken UX End state:
All users must see a standard strikethrough price when deals are applied which is the same BAU listing price when no deals are applied.
High level requirements:
Listing price sanity:
Revert the listing price inflation logic [Tech] Applied deals will give the same end customer price but perceived discount % for users will be lower. We want to A/B this to measure and understand the conversion loss impact. Communicate and reset expectations with sellers on input discount % and output discount experience Downstream system support:
All downstream systems must capture and index the right variables of discount and price which will be user specific Core requirement
Discount % to be calculated as (Listing price - deal price)/Listing price. [Note: Listing price includes the shipping price and is the BAU price before the deal has been set] In the above state, strikethrough price when deal is applied and non-deal price (BAU price) should always be the same Discount calculation must be revised at all flows: Recently viewed strikethrough price Price details (clicking on info icon next to PDP price) Cart screen (PID level info) Cart screen (Price details) Order summary screen (PID level info) Order summary screen (Price details) Since the above change will have conversion impact, we need the change to be behind an A/B flag for 0 order and 1+ users (signed in and non-signed in). Users on control cohort will see the existing experience while users on the test cohort will see the revised discount calculations. No new instrumentation needs to be developed Downstream sort handling -
During run time, we would index real time final price for the first 100 (Configurable) catalogs from OFS Post this final sort would happen on the final price / dynamic discount values and would be returned from FA in batches of 20 The details will be stored in feed aggregator redis and would then be served upstream to store front Downstream filter handling -
We would call the first 100 (Configurable) catalogs from OFS The filter check will be configured on feed aggregator library (FA commons) which will be applied on final user price / dynamic discount on run time The details will be stored in FA redis and would be served upstream to store front
Aligned solution approach -
PRD - Zonal pricing mismatch