Demographic Scoring - Job Title Change

[Kana_Ng]

Hello!

I'm trying to account for job title changes in demographic scoring. We've identified titles that we give a high (+5), mid (+3), and low (+1) score. However, if someone already received +3 for a mid job title, I only want them to receive +2 if they move to a high job title. I thought about creating smart lists for high, mid, and low and 3 smart campaigns for each list.

Example:

I don't love this approach because this would require multiple campaigns and I'm trying to be as simple and streamlined as possible. Is there a better way to do this?

[MitchellH]

There are a lot of different ways to approach scoring. Trying to take care of all scoring logic for a single profile element in one flow might not be possible with more complex requirements like these, however you should be able to manage it in this case, just build two smart lists to define people who became "high" with no previous "mid" status, and people who became "high" with a previous "mid" status. Then in your flow step, check for membership in each of those and apply the +5 or + 2 as required. Then, provided the trigger was consistent you could do the whole thing in one flow.

[Kana_Ng]

I like your idea to use more smart lists than campaigns. How would you account for people who have a mid job title, then change titles but the new title is still considered mid?

[MitchellH]

This is all a lot easier if you have a "job title level" field and set up a program to populate and update that field based on job title changes, rather than add to static lists. Then on the trigger for your scoring you can use the "old value" and "new value" constraints on the "data value was changed" filter as Sanford suggests. Then you can use a choice step to either award score based on the new job title level, or if you want to have caveats based on their previous level, then set up a smart list for each unique scenario and base your choice steps on those smart lists.

If you absolutely have to use static lists, the above is still possible but you have to use a bunch more filters to determine what list a person was previously a member of in lieu of their previous job title level value. Not too sure if list membership as you've set it up is permanent or whether you get removed from old lists when you move to a new list. Either way it's more difficult to work with.

[SanfordWhiteman]

Multiple (executable) campaigns are fine. And much less fragile than static lists.

On Change Data Value, use choices based on the Old Value and New Value.

[Jay_Jiang]

Demographic scoring, unlike behavioural scoring, can be recalculated since it's looking at static values in fields rather than activity over time.

My recommended approach to implementing demographic scoring has been to create a requested campaign that basically contain various CDVs with choices (with the release of executable campaigns, I've switched to using 1 executable campaign per demographic scoring rule). It gets requested on person creation and, in your case, it can be requested again when fields partaking in demographic score calculation change (remember to set the score back to 0).

You'll want to put in a few minutes wait step at the start and also limit people to running through the smart campaign once per hour so to avoid spamming the smart campaign and race conditions.

[SanfordWhiteman]

But a Wait step itself won’t avoid race conditions. If someone can execute the campaign multiple times in near-parallel, you’d just be delaying them all by the same N seconds. The race then resumes after that.

You can however use a sentinel field like Rescoring Active as of DateTime. Then use that field to determine whether someone should reenter the process immediately or wait and check the field again.

[Darshil_Shah1]

For one of our clients, we set up a nightly scoring reset batch campaign which would basically reset the scores in case somebody's demographic attribute changes, and re-run them through the demographic campaigns (these were separate reset campaigns from the ones that scored person for the first time when their demographic attribute got populated). Since this client wanted to update the score for every demographic field, and each field had significant values for us to create and manage separate smart lists (as reqd. in the approach discussed by, @MitchellH), we came up with this approach.