Customer group is a data model in Blueshift that can be used to support households and multiple customer identities with shared attributes. In this model, different customer profiles are linked to a common parent entity called a group.
Each account on a streaming platform would correspond to a group in Blueshift and each profile under an account would correspond to a customer profile. A group would have the account contact and billing information while each customer profile under the group would have details specific to each user for example preferences and contact information.
Similarly for a mobile service provider, a group can be used to represent a billing account while a customer profile can be used to represent each individual under the group plan.
In the B2B space, a group can be used to represent a prospect or lead (e.g. a company or organization) while customer profiles under the group can represent the different contact persons for that organization.
Sometimes a single individual can have multiple identities e.g. multiple email addresses with which they have signed up for different services from a given brand. In such situations, the group can be used to represent the individual while customer profiles under the group can be used to represent the different identities of the individual.
Group vs Customer Attributes
A group has a few standard attributes:
• Group ID
• First Name
• Last Name
In addition, you can provide as many custom group attributes as necessary for your use case. For example for a household type model you could have group attributes like
• Subscription start date, subscription end date, household income, etc
• Statuses such as bill paid, renewed subscription, overages, etc.
A group can have one or more customers. The screenshot below shows a group with 2 customers.
Fig 1: Screenshot of a group details page
Group level attributes apply to every customer that is a member of the group whereas customer attributes are limited to a specific customer only. During segmentation, you can segment customers both on customer attributes and on group attributes and statuses.
Fig 2: Shows 2 users C1 and C2 each having individual attributes and shared group (G1) attributes
Group vs Customer Events
When the group feature is enabled, events get classified as group or customer events. Events with group_id are treated as group events and are associated with all the customers in that group. Events with just the customer_id (or email_id) are treated as customer events and get associated with only a specific customer.
Fig 3: Shows a group (G1) event and its association with all the members (C1 and C2) in the group
Fig 4: Shows a customer (C1) event. Note that it’s associated with the customer C1 only and not with any other member (C2) belonging to the same group (G1)
You will first need to contact your CSM to enable the customer group feature for your account. You can then create groups, add users to groups and create group transactions by firing the below mentioned events on BSFT.
The sample payloads are for illustration purposes only. You will need to modify these as per your use cases.
Step 1: Update transaction configuration to support groups:
:id => 1,
:account_id => 15,
:user_id => 1,
:description => nil,
:transaction_name => "lds",
:event => "lead_initial",
:user_exclude_attributes => ,
:group_exclude_attributes => ,
:transaction_id_attributes => [
:transacton_id_delimiter => "-",
:transaction_resource_type => "group",
:version => "2",
:active => true,
Step 2: Publish a group transaction
For household use cases, groups allow you to:
- Get a summary view of all customers in a household (e.g. billing_account_number)
- Report on campaign activity both at the household level (e.g. billing_account_number) and at the individual level (e.g. email or customer_id)
For identity management use cases, groups allow you to:
- Manage spam/hard bounces at the individual level (e.g. account_number) in addition to the doing so at the identity level (e.g. email)
- Apply messaging limits at the individual level (e.g. account_number) instead of doing so at the identity level (e.g. email)