Typology rule to prevent same delivery to recipient i...

[blmcghin]

Friends,

I want to create a typology rule that prevents a recipient from receiving the same delivery within a 24 hour period. I don't want to limit the overall number of deliveries they will receive, which pressure rules do by default, I just want a safey valve of sorts to prevent a recipient from receiving the same delivery more than once in the same day. Filtering rules don't allow me to define a time period so I think it has to be a pressure rule, but I can't figure out how to configure it so that it dynamically takes the incoming delivery id/recurring delivery id and compares it to the recipient's existing delivery/recurring delivery ids in the recipient delivery log. I would expect the query would look something like this, with each of the Values essentially being the delivery ids from the delivery being executed. The configuration below doesn't seem to be working and I'm at a loss. Thanks for any help you can offer.

[Jonathon_wodnicki · Accepted solution]

Hi,

Pressure rules don't let you specify same-delivery (same-delivery...code?), and filtering rules don't have access to delivery metadata afaik.

This leaves control typology and post-processing workflows as the only points to implement this check, with control being the easiest and most maintainable.

Thanks,

-Jon

[Tobias_Lohmann]

Hi Jon,

I think there is a way to access the current delivery metadata. You can access an object called currentDelivery; I didn't find documentation for this, but it seems to work in my test cases.

So, to filter out recipients that have already received a message with a certain delivery code (or any other [custom] field) you could create a filtering typology and set up a filter:

broadLog exist such as
  [delivery/@deliveryCode] equal to [currentDelivery/@deliveryCode]

 I tested this with a recurring delivery that I add recipients to each time it runs and it filters out the recipients who already received it. 

Cheers, Tobias

Disclaimer:

1. I'm not sure how this behaves in large audiences

2. it relies on broadlog which is deleted after defined time

3. you should always try to select and filter the right audience upfront and not only rely typology rules; they are basically just the safety net

4. for recurring deliveries you could also look at continuous deliveries or incremental queries.

[blmcghin]

Thank you for replying Jon. We were able to create a Filter rule where the current delivery is excluded whenever a delivery in the recipient delivery logs matches, based on two custom delivery attributes that appear to carry through in the backend when the typology rules are applied. We simply added a "current date - 24 hours" condition so that it is timebound. So far it seems to work just fine, but definitely showed this didn't work quite the way we would have expected. To your point, comparing on Delivery ID or Recurring Delivery did not seem to work, as it seemed those values weren't accessible somehow when the rules are applied. This is counter intuitive but we tested over and over again trying to make that approach work. Thanks again for your reply!

[sanderc51378852]

Hello , 

I've got the same issue, but when i create the same typology rule as @Tobias_Lohmann the rule always states that 0 recipients are excluded. Don't let the naming confuse you - the 180 days limit is not configured.

Is there something obvious i've missed ? 

Thanks in advance!