AND and OR Node Rules for SAS 360 Direct

[#1]

When building targeting segments using the AND and OR nodes, users have a choice between two rules that are used to process a node’s counts. This year, a new setting was released for Business Contexts where a “default” can be set between the two 2 available rule methods.

This Business Context default setting is somewhat new, but the actual rules available in the AND and OR nodes are not new. The default now makes it easier for some customers to ensure they use the correct method.

These two rule methods could provide the same results, or different results depending on the data being processed. Let’s take a look at the difference between these two available methods and how to set the default for a business context.

The Two Rules

Here are the two options for the AND node rule:

• Meets all conditions defined by input nodes. This is the default option (unless you change that!), and it works the same way that a logical AND works.
• Is a member of each group defined by input nodes. This second option works like a SQL intersect command.

Here are the two options for the OR node rule:

• Meets any conditions defined by input nodes. This is the default option (unless you change that!), and it works the same way that a logical OR works.
• Is a member of any of the groups defined by input nodes. This second option works like a SQL union command, which often results in the same segment.

Let’s explore an example of an AND node to see how it is possible to get different counts between the two methods. This is a simple example where we want an AND node to be populated with Household subjects that contain at least one customer subject that is female and age>30:

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

The first rule Meets all conditions defined by input nodes as already stated works the same way that a logical AND works. So a household will be included in the count if it has a least one customer that is BOTH female and age>30. So to make it very clear, if a household contains only one customer that happens to be female and age 25, that household will not be counted.

The screenshot above shows the result of using this first rule: 78,861 Households.

The second rule Is a member of each group defined by input nodes as stated works like a SQL intersect command. This rule works different in that it will count a household in our example if:

1. Similar to rule one, if any customer is BOTH female and age>30,
2. If any customer in the household is female, and any customer in the household is age>30. Therefore, if a household has 2 customers and 1 is female age 25, and the other is male age 45, then this household will be counted because collectively it has a least one customer that is female and also at least one customer with age >30.

Here is an important point: the two rules could produce different counts if you are using aggregated data. In this example, we are using Households as the subject. A household can contain multiple customers with various values for both age and gender. This “many to one” relationship between customer and household subjects is what can yield different results depending on which rule is applied.

If the rules produce different counts, the second rule will always produce a higher number because it will count the exact same as the first rule, plus any additional (households in this example) that meet the criteria that works like an SQL intersect command. In this example, that proved true – by changing the AND node rule to the second rule and re-running an update of the counts – this produced a higher number of 80,348 households:

Default Within Business Context Settings

To set the default rule, use the Business Context Settings tab->Options to select a rule such as below for the AND node (hint: the ? in the UI provides a nice pop-up summary of how this works):

Please note it will be recorded in the Audit Log if a user changes the default method in the Business Context Settings.

For more details and information on building segments using AND and OR nodes in SAS 360 Direct, please visit these sites below:

• SAS Customer Intelligence 360 User Guide
• SAS Customer Intelligence Learning Subscription

Courses:

• Building Segments using SAS Customer Intelligence 360
• SAS 360 Direct – Defining the Marketing Data and Business Contexts

Find more articles from SAS Global Enablement and Learning here.

[Hassan5]

This is a really clean breakdown of how relational database intersections work vs logical ANDs, especially when dealing with one-to-many household relationships.

One thing that always catches people off guard with filters like "age > 30" is how the source database handles date-of-birth transformations. To keep our segmentation runs fast in SAS, we usually have to pre-calculate age brackets in our database layer. When I am QA'ing the boundary dates to make sure our SQL logic isn't pulling in off-by-one errors (especially around leap years or threshold dates), I often run a few mock profiles through a free online tool to double-check the exact day differences. It's way faster than writing manual queries just to verify age boundaries before running the counts.

These Business Context defaults are definitely going to save a lot of headaches in larger teams where users might not fully grasp the difference between logical and group matches. Thanks for sharing!