Segmentations Using Custom Object Data

Anonymous
Not applicable

Some of you may have noticed that you cannot currently use custom objects in segmentations. I have been lobbying for this feature for a while, but until it's available, never fear - another patented Kristen workaround is coming your way.

Why would you want to do this? Some examples of the use cases I've heard of:

  • Sending people different emails based off the product they've ordered, which is stored in an order object
  • Grouping people based on their brand preferences, which are also stored in a 1:N fashion since there are many brands

So what's my trick? Instead of using the custom objects in the segmentation, I use static lists and I create smart campaigns to add and remove people from the static lists based on the custom objects. Basically, the static lists become a middleman that allow me to use custom object data to define my segmentations.

Let's consider the case where I want to vary a welcome email's content based off the product, which is stored on a Sales Order custom object in Salesforce. The name of the product is stored in the Product Code Name field. First, create one static list for each product (Yes, I've deleted the product names to protect the innocent, I didn't magically name all my lists the same!):

pastedImage_5.png

Then create a smart campaign to listen for a new sales order that comes in with that particular product type. When you are using Dynamics, you can add this constraint directly to the custom entity trigger so you know that the constraint applies to that exact custom entity. When you're using Salesforce, you can't do this, so you need to combine the trigger with a filter that contains the constraint. In this case, we combined the Sales Order trigger with a filter for the Sales Order where we're further limiting the sales order by product and also by date (in this case, the date of shipment, but you could also use created date). This gives us a very high probability that this person is going to get added to the list based on that specific custom object having that specific product. (Again, not a concern with Dynamics!)

pastedImage_6.png

pastedImage_9.png

In the flow of this smart campaign, add the person to the relevant static list that you created earlier.

Then, create a segmentation that has one segment for each product. In the smart list for this particular segmentation, we opted to include people who were on one product's list but not on any of the others. (We decided that if you were on the list for two products, you should get a generic email.)

pastedImage_12.png

Once you have all your segments defined, approve the segmentation and use to make your email dynamic as desired.

Really Important Things to Consider

It's important to remember when you are doing this that you need to take into account a few things that are not considerations when you build segmentations off company or lead fields:

  • The segmentation will not update automatically when the custom object changes. Because the segmentation is actually built off a static list, you need to set up campaigns that will add and remove people from these lists if you want them to move from segment to segment. Only when that happens will your segmentation be updated. This does mean there will be a slightly longer delay for updates to the segmentation (and it may not always be 100% accurate), particularly if you are running these as batch campaigns.
  • Since people often have more than one custom object associated to them, you will run into issues where people qualify for more than one segment more often than you do when using lead/company filters. Remember the way we handle this by default is by the order of the segment. The lead will always end up in the segment they qualify for first, so order is super important. I recommend that when you are building segmentations off custom objects indirectly like this, that you strongly consider more robust exclusion criteria in your segments' smart lists so that you have more granular control over how that happens.
  • This is not a solution I'd recommend using all the time for really large volumes of data. It does add a bit of a performance burden on the instance in those cases, so use judiciously.
3529
2
2 Comments