Skip to content

Planning price changes

Introduction

This article describes different approaches to what can be done to handle price changes for products in Ecommerce Search.

Sale

Some of all products go on sale at a specific time for a limited time period.

Each price entry contains a ValidFromUtc timestamp. This can be set to the time the price must take effect. If not set, the ValidFromUtc will default to the minimum value, making the price effective immediately.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
await client.PatchSkusAsync("mysegment",new SkuPatchBulkRequestModel
{
    Skus = new SkuPatchBulkModel[]
    {
        new ()
        {
            SkuId="sku-1",
            Prices=new SkuPriceContainerModel
            {
                PriceGroupPrices =new SkuPriceModel[]
                {
                    new SkuPriceModel()
                    {
                        PriceGroupId = "default",
                        ListPrice = 1000,
                        Price = 1000
                    },
                    new SkuPriceModel()
                    {
                        PriceGroupId = "default",
                        ListPrice = 1000,
                        Price = 900,
                        ValidFromUtc= new DateTimeOffset(2024, 1, 1, 12, 0, 0, TimeSpan.Zero);
                    },
                    new SkuPriceModel()
                    {
                        PriceGroupId = "default",
                        ListPrice = 1000,
                        Price = 1000
                        ValidFromUtc= new DateTimeOffset(2024, 1, 31, 12, 0, 0, TimeSpan.Zero);
                    },
                }
            }
        }
    }
});

In the example above the price is 1000 until the 1st of January 2024 12:00, then it is 900 until the 31st of January 2024 12:00, and then 1000 again.

It is important to notice the following limitations:

  • Any price group in use must have a valid price on call time. I.e. if all ValidFromUtc are set to a point in the future, the ingestion request will be rejected.
  • All timestamps will be floored to the hour. It is not possible to plan price changes more granular than on the hour. However, any SKU ingestion requests that change the current price of a SKU will take immediate effect.

A naive alternative

The alternative is to call the SKU ingestion API whenever the price of the SKU changes. This approach is simpler but some latency must be expected. Also if all prices change then it will take some time before they take effect.

Customers with different discounts

If some customers have different discounts that can be grouped. This could be that one group gets 10% discount on all products and another group get 20% discount on all products. In this case all skus should have 3 prices. There are no fallback to the default price group. See the example below to get an idea on how to set it up.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
await client.PatchSkusAsync("mysegment",new SkuPatchBulkRequestModel
{
    Skus = new SkuPatchBulkModel[]
    {
        new ()
        {
            SkuId="sku-1",
            Prices=new SkuPriceContainerModel
            {
                PriceGroupPrices =new SkuPriceModel[]
                {
                    new SkuPriceModel()
                    {
                        PriceGroupId = "default",
                        ListPrice = 1000,
                        Price = 1000
                    },
                    new SkuPriceModel()
                    {
                        PriceGroupId = "10_group",
                        ListPrice = 1000,
                        Price = 900
                    },
                    new SkuPriceModel()
                    {
                        PriceGroupId = "20_group",
                        ListPrice = 1000,
                        Price = 800
                    },
                }
            }
        }
    }
});

When using price groups then authenticated search should be used.

Vouchers, Coupons or Promo Codes

If the solution is using vouchers, coupons or promo codes then this should not be implemented in Ecommerce Search unless they are very simple then it might be possible to use price groups to solve this problem. Otherwise the handling of prices should happen in the customer solution. This will have that inpact that sorting on prices will not be correct.