Skip to main content

Customer_Segment_automation

  • New requirement:(for 1.0 release): The linking of concern codes should automate the customer segmentation attributes, where system should check the parent code (Is Concern) and enrich or revise the child codes' attributes to match the Parent code. If any of the attributes is not available in the Parent code but present in the child code, then retain the value in the child code. If there are any edits to the parent code segments (listed below), then CMD should replicate the new values to the child codes. At any time, CMD must ensure that the parent code values for the below-listed attributes are replicated to the child codes.
    • Attractiveness
    • Rolling protection flag / Loading Priorities
    • Value Proposition
    • Industry
    • Vertical
  • New requirement: (for 1.0 release): The delinking of concern codes of a child/parent concern should drop (update the field as blank) the customer segmentation attributes for the below attributes only. @Vinesh Ashokan why are we delinking only Attractiveness and Rolling protection flag. Q2: if child has different value than parent, what should be the action? Q3: what should be the action on existing discrepancies? @Praveen Shetty @Ajit Vijay Daware A1: Attractiveness & Rolling protection have a direct impact on container prioritization. So, once the customer is delinked from the concern, the business decision is that they will not enjoy the same benefits as they did when they were a part of the concern. The other values - value prop, industry/vertical are permanent in nature and will not change irrespective of whether the customer is part of the concern or not. A2 & A3: In the modern portal, all the child codes within a concern must have the same segmentation values as the parent code. Prior to going live there must be a clean-up to ensure the existing parent code segmentation values within a concern are applied to the respective child codes.
    • Attractiveness
    • Rolling protection flag / Loading Priorities
    • Value Preposition
    • Industry
    • Vertical

My Analysis on Customer segment Automation during concern Linking and de-linking:

This automation includes adding and removing segments to children concern-members in concern group from parent IS_CONCRN relationship.

  • All Active concern members in concern group should inherit parent customer segments.
  • Child concern members can have extra segment attributes which are not present in parent.
  • Any edits made on Parent Customer’s segments should also reflect for all active child concern members
  1. New segment is linked to Parent child should also have this segment
  2. De-linked a segment of Parent same segment should be de-linked from all children segments

When a concern member is linked, below segment attributes should be inherited from parent and linked

  1. Attractiveness
  2. Rolling protection flag / Loading Priorities
  3. Value Proposition
  4. Industry
  5. Vertical

When a concern member is de-linked, below segment attributes should be de-linked

  1. Attractiveness
  2. Rolling protection flag / Loading priorities
  3. Doubt: What If these two properties are not inherited from parent but own properties of child concern member
  • De-linking concern mem from concern group, do we de-link these segments also?
  • If above two properties are removed for parent concern, do we de-link for this child also?

Doubts:

Why don’t we have look up based on parent concern segments? By following look-up approach, we can avoid data redundancy and save time in processing automation of customer segments

Current Assign Segments API Implementation:

  • Fetch customer Information
  • validate, transform, and persist
    • validate Multiple Segments for Brand is allowed or not
    • validate Brand + segment Type + segment Value combination
    • transform request segment objects to entity objects
    • Check for brand agnostics and replicate segments for allowed brand agnostics
    • save the segments for customer
  • Sync and publish

Reusability of Assign segments API:

The validations present in assign segments API is not required in Customer segmentation automation during concern Linking and de-linking because, all the segments which need to be inherited from parent customer are already validated during and present in database.

So, we can directly proceed in inheriting attributes without validations. Using this API will make unwanted validations and increase throughput of Segment automation

Segments Inheriting from Parent to Customer:

Scenarios should be covered in automating

  1. Edits performed on IS_CONCRN
    1. Linking new segment
    2. De-linking a segment
  2. Concern member de-linked

Examples:

IS_CONCRNBrandSegment typeSegment value
IN123MAEUXA
IN123MAEUYB

A concern member has liked to concern group where above customer is parent

CONCRN_MEMBrandSegment typeSegment value
IN789MAEUXB
IN789SAFMYC

After segments automation

CONCRN_MEMBrandSegment typeSegment valueIS_DELETED
IN789MAEUXBY
IN789MAEUXAN
IN789SAFMYCN

Scenarios should be handled by Customer Segment Automation:

  • New Concern member linked to concern group
    • Inherit all parent customer segments as copies and link
  • Existing Concern member de-linked from concern group
    • Remove “SERV” and “ROLP” segments which are inherited from parent customer
  • When IS_CONCRN parent relationship is De-Linked, And New IS_CONCRN is Linked
    • Children segments inherited from this de-linked parent must be removed
    • And immediately Segment attributes of new IS_CONCRN relationship should be inherited as copies to all child concern members
  • When any edits happen on parent customer segments either Linking/De-linking
    • Same edits should reflect to all concern_members

Scope and Impact:

  • Assign customer segments API need Customer Segment Automation
  • Customer segment Automation should be able to handle requests from both relationships API and assigns segments API

Example Scenarios from segments link/de-link

  1. Link a new segment to parent customer of a concern group
    1. Link any segment in these {SERV, ROLP, VERT, INDU, VALP} attributes.
    2. Link any segment out of the above mentioned 5 attributes.
  2. De-link existing segments of a parent customer
    1. De-Link any segment in these {SERV, ROLP, VERT, INDU, VALP} attributes.
    2. De-Link any segment out of the above mentioned 5 attributes.
  3. Update value of any segment type
    1. Directly send update in single object
    2. Send Two objects individually: De-link segment object and newly linked object

Example Scenarios from relationships link/de-link:

Link/De-Link concern member to a concern group

Concern memConcern mem Existing SegmentsParent Concern existing segmentsResult
LinkzeroSERV, ROLP, VERT, INDU, VALPInherit all attributes, total 5
LinkVERT, INDU, VALPSERV, ROLPInherit both attributes, total 5
De-linkSERV, ROLP, VERT, INDUSERV, ROLP, VERT, INDUSERV, ROLP de-linked, total 3
  1. De-Link and Link IS_CONCRN from concern group
    1. De-Link SERV and ROLP attributes of concern members
    2. Implementation: Fetch all active SERV and ROLP segments irrespective of brands of current de-linked IS_CONCRN. Now use collected active SERV and ROLP segments to de-link from all children
    3. Link Newly Linked IS_CONCRN’s segments to children
    4. Implementation: Fetch active {SERV, ROLP, VERT, INDU, VALP} segments irrespective of brands and link to concern-members

TEST EVIDENCE:

  1. Link a new segment to parent customer of a concern group
    1. Link any segment in these {SERV, ROLP, VERT, INDU, VALP} attributes.

Assigning SERV and VERT segments to Parent customer

Active Relationships

After assigning segments to parent customer

One of the concern mem segments automated

All the Four concern member segments automated

All these four customers will be autos synced to elastic and published

Publish evidence

b) Link a segment which is not inheritable

Link MCPU brand and SERL Segment type to parent customer. This segment shouldn’t be inherited by any children

Database result

Check whether this segment is linked to child customers

De-link existing segments of a parent customer, De-Link any segment in these {SERV, ROLP, VERT, INDU, VALP} attributes.

De-linking SERV segment from parent customer. Same segment must be de-linked from all its child customers

Database result

From the below result, Confirming SERV segment from all children customers de-linked

Elastic sync result: Including parent customer, all children customers should get de-linked with SERV segment

Update Inheritable segment values for parent customer. All its children should also adapt same changes

Updating segment value for VERT segment type

Database result

Child customer segment updated

Checking for other customers also

  1. De-linking a concern member from a concern group

Concern member to be de-linked have SERV and ROLP segments which are inherited from parent customer. After concern member de-linked from concern group both segments should be de-linked

De-linking two concern members

Existing segments for these two customers:

After de-linking

Customer Relationships

Customer Segments details for two de-linked customers

SERV AND ROLP segments are de-linked

For Second child concern member after de-linked

Customer segment details

Was this page helpful?