A requirement that we sometimes come across is to have region based product assortment and pricing. FMCG and grocery retailers typically have different pricing and product assortment in their physical stores and the same needs to be replicated in the online channel. Running local promotions and offers is also quite common, for example, for a local festival or event.
There are multiple ways to achieve this requirement and the approach you choose to implement depends on the level of differentiation required among regions. Let’s explore some of these approaches.
The definition of region is kept intentionally loose here. Multiple countries could constitute a single region. Each country could form a region or one country could be made up of multiple regions.
The region to which a user belongs could be identified using many different approaches. It could either be through the user provided zip code or by using a geo-location service. This discussion is out of scope of this article. All we really care about is that before a user starts browsing the catalog, her region has been identified and saved somewhere, be it in a cookie or in the database.
Approach 1 - Multiple extended sites
This is probably the first approach that comes to one’s mind. The structure and concept of extended sites lends itself well to this requirement in general.
Each region can be represented using a separate e-site. Each e-site can have its own sales catalog that offers a subset of the products available in the master catalog in the catalog asset store, thus offering a different product assortment.
Each e-site could have its own price rule which could override the prices from the master catalog as needed.
The e-sites can even have their own UI differences and region specific marketing and promotions.
If the number of regions is very large then similar regions could be combined into a single e-site with the minor differences within those regions being implemented using other approaches discussed here.
Approach 2 - Multiple catalog filters in B2C store model
In the B2C store model, the store’s default contract is used to define the default entitlement of the store. All customers shop under this one contract which by default provides the same catalog and pricing to all users. There are ways to work within this default contract and offer differentiated catalog and pricing.
You can create multiple catalog filters and add them to the default contract using the CatalogFilterTC term. Each TC should have a TC level participant for a member group (region specific) which means that the TERMCOND_ID & MEMBER_ID columns in PARTICIPNT table will be populated while the TRADING_ID will be NULL. See the definition of PARTICIPNT table for details of these columns: http://www-01.ibm.com/support/knowledgecenter/SSZLC2_7.0.0/com.ibm.commerce.database.doc/database/participnt.htm?lang=en.
The default contract cannot be edited through WebSphere Commerce Accelerator, so to add the catalog filters to it you either need to use the contract XML import command (ContractImportApprovedVersion) or write custom data load configurations using TableObjectMediator to load the data into the required tables (TERMCOND, PARTICIPNT etc).
The default contract always has one price rule associated with it. The price rule can include different branches of pricing for different member groups thereby allowing for different pricing. Alternatively, you could create a custom price rule condition that checks for the user’s region (assuming it is saved somewhere – cookie or database) and use that to decide which path to follow.
Refer to this topic in info center on how to create custom price rule conditions:
Adding a new custom condition or action for a price rule
For this approach to work, the customers need to be added to region specific member groups. Only static member groups, i.e. member groups that have users added to them explicitly, can be used as TC level participants. Users can be added or removed from member groups dynamically, but you need to write custom code to map the shoppers with the appropriate member groups. This can become a performance bottleneck, particularly if the retailer has a very large user base.
Approach 3 - Multiple buyer contracts in B2B store model
If you are using the Enterprise edition of WebSphere Commerce, you can use the B2B store model in a B2C scenario with some adaptations.
Starting from Feature Pack 8, a single Aurora based storefront for both B2B and B2C capabilities is offered. When publishing the Aurora store archive you can choose to publish it as a B2B storefront and then disable the B2B features that you don’t require, for example, requisition lists, saved orders etc. Some of these features can be disabled using the Store Management tool in Management Center, while some might require JSP changes.
The benefit of basing your B2C store on the B2B store model is that you get the B2B business user functions; for example, you have the ability to manage the buyer contracts using WebSphere Commerce Accelerator.
In Feature Pack 7 and earlier, you can use the Elite starter store as your store’s base and again adapt it for B2C, i.e. enable guest user shopping and disable the features you don’t need.
If you don’t need the B2B business user functions, you can base your store on the Aurora B2C model too. In this case, you can manage the contracts either through contract XML import command (ContractImportApprovedVersion) or write custom data load configurations using TableObjectMediator to load the data into the required tables. Data load is particularly useful when managing a large number of contracts.
Whatever store model you choose to go with, the rest of the approach described here will remain the same.
Product assortment and pricing
Each region can be mapped to a buyer contract with each contract being associated with a unique catalog filter and price rule. A catalog filter can be assigned to a contract through a TC of type CatalogFilterTC and a price rule through a TC of type PriceRuleTC.
For a given contract, only a single price rule can be in effect at one time. Therefore, the price rule you assign must generate prices for every customer and for every catalog entry available to customers under the contract.
The contracts need to be applicable for all users. This is handled through contract participation where one row in PARTICIPNT table with MEMBER_ID value NULL having a ‘buyer’ participant role in each regional contract is created. This allows for any user to shop under the contract.
Once the customer’s region is identified, the corresponding contract can be set in the session using ContractSetInSession URL. Once this is done, the customer will see and be entitled to the region specific product assortment and pricing.
For contracts and catalog filter to be used at runtime, search entitlement needs to be enabled. This is required since from Feature Pack 7 onwards, browsing and searching as non-transactional requests were offloaded to the search server. As a result, the WebSphere Commerce server acts as a transaction server, and the search server acts as a non-transactional server that can be separately deployed and scaled. Entitlement was moved to the search server to apply entitlement checks before and after search results are returned in the storefront. If you use the Aurora storefront from Feature Pack 7, you will need to update the product and category REST calls in the JSPs to pass in the contractId that is set in session, so that it is used by the search server to enforce the entitlement.
By default, search entitlement is disabled for B2C stores and enabled for B2B stores. You can insert or update an entry with the name ‘wc.search.entitlement’ and value 0 (disable) or 1 (enable) in STORECONF table.
If the regions have simple UI differences, then those could be managed through contract specific style sheets where you can follow a naming convention for the files so that the appropriate one is picked up. For example, the name of the CSS file could be same as the contract name. Alternatives could be designed using the same concept (map the UI differences to the contract) if the UI differences are significant, but this would require customization.
Marketing and promotions
If region specific marketing and promotions are a requirement, then region specific customer segments can be created to target the customers. The customer segments can be created as static member groups, i.e. member groups that have users added to them explicitly. Users can be added or removed from member groups dynamically, but you need to write custom code to map the shoppers with the appropriate member groups. And as discussed in the previous approach this can become a performance bottleneck.
An alternative is to not include any explicit members or implicit rules of membership when creating the customer segments. So, all customer segments are actually identical copies of each other with only the names being different. To identify a specific customer segment as belonging to a particular region, the relationship between a region’s customer segment and contract can be stored in a custom table. You can customize the member group checking logic to return true when evaluating the customer segment of the region that the customer is currently browsing. Essentially, every user will be treated as a member of the regional customer segment only when they are browsing the contract of that region.
You can then use the customer segment while defining a promotion or a marketing activity. Refer to the screenshot below for an example of a region specific product recommendation.
This approach of using multiple buyer contracts works well when the number of regions is not too high. If you have a large number of regions, then that would mean a large number of eligible contracts for each user since each user is eligible to shop under any contract. WebSphere Commerce server and search server scan through all eligible contracts of a customer at multiple points. Therefore, having a very large number of eligible contracts can impact the performance of the storefront.
WebSphere Commerce provides a flexible and powerful architecture and runtime framework. As a result, there can often be multiple ways to implement a given requirement. In this blog post, we discussed the approaches that can be implemented to offer region specific products, pricing, UI, marketing and promotions. You should be able to evaluate the approaches given here and map them to your business requirements to select the best approach that works for you.