Migration of static contact groups from Kentico Xperience 13 to Xperience by Kentico

Hey everyone,

While automatic migration of Contact Groups is not supported by the migration tool, we faced a couple of cases during migrations where the end client used static contact groups (that were originally imported and regularly synced from CRM) for the personalization. I wonder if anyone in the community faced similar challenge and how you dealt with it?

We are exploring options of issuing / removing a special custom activity for these contacts and use this custom activity in contact group condition builder. But maybe there's an easier way of approaching this? Any thoughts?

Regards,

Dmitry

Tags:
Customer segmentation Contact groups

Answers

Accepted answer

I was just talking about this with someone.

I like your idea of a custom activity, but it could be confusing if you intend for that activity to actually represent an engagement at a specific point in time.

What about a custom field on the Contact that acts as an attribute targeted by the Contact Group? If you only plan to use static Contact Groups as a legacy feature for upgrade compatibility this might be the best approach - it would be simple to clean up the data at a later date.

However, this won't scale as well as a custom activity if Contacts can be in multiple static Contact Groups.

Thanks @Sean, I'm also considering this option of adding a custom field to contact and you can even store a selection of group names there, not necessarily one group name.

On one other project, where this static group was used for capturing leads after form submission for further post-marketing we ended up with switching this logic to a consent instead (and during migration we just issue consent agreements based on static group membership in KX13).

I think all these examples demonstrate one thing - there are multiple options how we can achive similar type of functionality in XbyK, and you need to make a final decision based on the actual business requirements and what you are trying to achieve with this solution, rather than just trying to find the closest technical alternative to how it was done in KX13.

To response this discussion, you have to login first.