In some projects the customer segmentation is done in another system and there is no easy way, except from the existing import to static segments, to determine customer segments live from outside. This means dynamic segmentation from a 3rd party system requires a tremendous amount of project work.
So a need for dynamic segmentation in standard Intershop product is identified. This leads to introduction of a new managed service: the Customer Segmentation Service. It is intended to make it much easier to exchange and enhance the standard segmentation service with a 3rd party integration that delivers the customer segments for a user or determines if a user is part of a specific segment.
Concept - Managed Service Framework
Cookbook - Customer Segmentation
The customer segmentation managed service has to provide CustomerSegmentBOs. A standard implementation exists which delegates the retrieval of CustomerSegmentBOs to the default UserGroupPO / ConsumerGroupPO internal implementation. In addition to this, it is possible to create other implementations of this service which serve as adapters to external systems which in turn provide other customer segments. It is possible to have several segmentation services running simultaneously providing segments from various sources - the different implementations are not exclusive, but they work together, meaning that all retrieved customer segments from distinct customer segment BO repositories can be combined.
It should be possible to assign a customer segment to other business objects, regardless of where the segment came from (internal customer segmentation implementation or external system). This is possible for the standard business objects to which customer segments can be assigned, like Price Lists, Catalog Views, Promotions, Campaigns and A/B Tests.
There are 2 new cartridges created, part of f_checkout component set:
There is one additional cartridge which contains a CAPI test checking if the default service implementation is correctly registered in the services registry.
The interface for customer segmentation service is defined in bc_service cartridge - com.intershop.component.customer.segment.capi.service.CustomerSegmentationService
:
/** * Defines interface for services which provide customer segments from some * internal (Intershop) or external source (system). */ public interface CustomerSegmentationService { /** * Retrieves all customer segments the provided {@code customerBO} belongs * to. * * @param customer * the {@link CustomerBO} instance whose assigned customer * segments need to be retrieved. The argument can be null. * @return a collection of all {@code CustomerSegmentBO} instances assigned * to the {@code customer}. It is expected that implementations * will return a non-null result. */ public Collection<CustomerSegmentBO> getCustomerSegments(CustomerBO customer); /** * Retrieves all customer segments known to this service. * @return a collection of all {@code CustomerSegmentBO} instances. * It is expected that implementations will return a non-null result. */ public Collection<CustomerSegmentBO> getAllCustomerSegments(); }
The standard service definition resides in ac_customer_segment_std cartridge: com.intershop.adapter.customer.segment.standard.internal.StandardCustomerSegmentationServiceDefinition
. The ac_customer_segment_std cartridge also contains the component implementation and instance needed for registration of this standard customer segmentation service in the manged services registry:
<implementation name="com.intershop.adapter.customer.segment.standard.internal.StandardCustomerSegmentationServiceDefinition" class="com.intershop.adapter.customer.segment.standard.internal.StandardCustomerSegmentationServiceDefinition" implements="ServiceDefinition"/> <!-- Registering the ServiceDefintion instance to the (global) ServiceDefinitionRegistry --> <fulfill requirement="serviceDefinition" of="serviceDefinitionRegistry"> <instance with="ServiceDefinitionRegistry.Entry"> <fulfill requirement="cartridgeID" value="ac_customer_segment_std" /> <fulfill requirement="groupID" value="service.group.name.CustomerSegment_Services" /> <fulfill requirement="serviceDefinitionID" value="StandardCustomerSegmentationServiceDefinition" /> <fulfill requirement="localizationKeyForName" value="service.definition.name.StandardCustomerSegmentationServiceDefinition" /> <fulfill requirement="serviceDefinition"> <instance with="com.intershop.adapter.customer.segment.standard.internal.StandardCustomerSegmentationServiceDefinition" /> </fulfill> </instance> </fulfill>
Because the CustomerSegmentBO is a business object it should be managed by a CustomerSegmentBORepository. So it is expected that implementations of the customer segmentation managed service that connect to an external system make use of a CustomerSegmentBORepository, that is specific to that service definition or the external system the service connects to.
Extending the com.intershop.component.customer.segment.capi.service.AbstractCustomerSegmentationServiceDefinition
abstract class in bc_customer_segment removes the need for a custom implementation of the service interface. Instead only a custom CustomerSegmentBORepository is needed. In this case com.intershop.component.customer.segment.capi.service.StandardCustomerSegmentationServiceImpl
is used as implementation of the service interface. This standard implementation is simple - it just retrieves all segments by a CustomerSegmentBORepository and uses ORMCustomerSegmentBOImpl.isCustomerBOAssigned(CustomerBO) to determine which segments are assigned to the corresponding customer.