Understanding the Problem

In the current scenario, each customer has only one checking account, and the PersonID is used as the ContactKey. However, with the introduction of multiple checking accounts per customer, the PersonID will no longer be a reliable unique key. To address this, a unique customer ID, such as the UserID, can be used as the ContactKey.

However, this introduces another complication: a single UserID might have multiple DeviceIDs and contact points, leading to key conflicts. A possible solution is to use a composite key, which can be a combination of account ID, PersonID, and device ID.

The root cause of the problem is the lack of a unique identifier for each customer and their associated devices. The introduction of multiple checking accounts per customer breaks the current architecture, and a new approach is needed to handle the key relationships.

Possible Solutions

One possible solution is to use a composite key, as suggested by a community member. This can be a combination of account ID, PersonID, and device ID. Another solution is to use the unique customer ID, such as the UserID, as the ContactKey and maintain per-account attribute profiles under that user.

Additionally, teams running Journey Builder can use the Data Cloud identity resolution feature to resolve the customer identity and target specific devices for push notifications. This feature can help to identify the correct device for each account and send push notifications accordingly.

Implementing the Solution

To implement the solution, the following steps can be taken:

example.ssjs

var accountId = 'account123';
var personId = 'person456';
var deviceId = 'device789';
var compositeKey = accountId + personId + deviceId;
// Use the composite key to identify the customer and their associated devices

Heads up: When implementing the solution, it is essential to consider the data quality and ensure that the composite key is unique for each customer and their associated devices.

Checklist

Best Practices for Handling Multiple Accounts Per Customer

• Use a composite key to uniquely identify each customer and their associated devices
• Maintain per-account attribute profiles under the unique customer ID
• Use the Data Cloud identity resolution feature to resolve the customer identity and target specific devices for push notifications
• Ensure data quality and uniqueness of the composite key
• Test and validate the solution to ensure it meets the business requirements
• Consider using Journey Builder to target specific devices for push notifications
• Use the API to write the device ID to an object accessible by the journey

Frequently Asked Questions

What is the best approach to design an architecture to handle multiple accounts per customer?

The best approach is to use a composite key, such as a combination of account ID, PersonID, and device ID, to uniquely identify each customer and their associated devices.

Can I use the UserID as the ContactKey?

Yes, you can use the UserID as the ContactKey, but you need to maintain per-account attribute profiles under that user to handle the key relationships.

How can I target a specific device for a push notification in Journey Builder?

You can target a specific device for a push notification in Journey Builder by using the API to write the device ID to an object accessible by the journey.

What is the Data Cloud identity resolution feature?

The Data Cloud identity resolution feature is a solution that helps to resolve the customer identity and target specific devices for push notifications.

Can I use a single PersonID as the ContactKey for multiple accounts?

No, you cannot use a single PersonID as the ContactKey for multiple accounts, as it will lead to key conflicts and break the current architecture.