Typology rule based on Recipient Dimension + Delivery Dimension - Expert advise required - Adobe campaign v7

[somasundaram_h]

Hi all, 

Seeking your expertise advise on the below scenario.

Scenario:

We have around 20 to 25 products. These product details are captured in nms:operation table(Campaign table and a custom field).

For each of the product, I need to have a different rule.

Eg rules:

• I should not send an email to a recipient(recipient1) if he already received an email for a particular product(product1) within 1 month.
• I should not send a SMS to the same recipient(recipient1) if he already received a SMS for same product(product1) within 2 month.
• I should not send a Push message to the same recipient(recipient1) if he already received a push message for same product(product1) within 45 days

Please check the below details too.

• There are around 70 combinations like this.
• For each of these, I have to create a dedicated typology rule. And I will get the product details by navigating from nms:recipient -> nms:broadLogRcp -> nms:delivery -> nms:operation -> product = product1.
• So finally, for each of the channel(Email/SMS/Push etc), I will end up at least 10-15 rules.
• All these rules will have to calculate the aggregate function(Count) in BroadLogRcp to check the number of communication received by the recipient(recipient1).
• Here, this will impact the performance as it is trying to check against a large data table with 1:N link.

Is there any easy way to achieve this kind of scenario?

Note: we can not use for Pressure typology rule as the pressure rule requires the contact date to be defined already for the rule to be validated. But we want to use regular deliveries(Contact date will be assigned when we execute)

[Amine_Abedour]

Hello @somasundaram_h,

Wow, indeed, that's a lot of conbinations!! And the performance might take a hit.
I believe that the pressure type typology rule is the best suited to your needs.
As for the issue of the contact date, it can be easily resolved by creating a typology rule that executes before the pressure to set a delivery contact date to ''now'' if the contact date is empty.

If you do not want to use pressure typology, a solution that will avoid making queries on the broadlogRcp table is to create a dedicated table linked in a 1:N relationship with recipient that contains "recipientId", "productId", "channel", and "lastContact".
The table can be refreshed once a day (preferably overnight) with a dedicated technical workflow.
A purge should be performed on it to prevent it from growing indefinitely (according to your example, data older than 2 months is no longer useful).
And in the typology rules, use this table instead of broadLogRcp.

Br,