Create hard bounce from offline Delivery Logs (Extern...

[Florian_Courgey]

Hi,

We are using an external agency to send mobile text messages (SMS & MMS). Our deliveries are configured to call a Post-Processing workflow that makes 1 HTTP call per broadlog (recipient) in realtime. The broadlogs status are then set to "Sent to Service Provider".

Finally, another workflow runs daily to update the broadlogs based on the feedback from the external agency. The broadlogs status are updated either to "Success" or "Failed".

The thing is that no "nms:address" record is created for the "Failed broadlogs" (which are "SMS" hard bounces). So a recipient with a failed broadlog may be retargeted again and again...

What is the best solution to handle this situation?

- Create "nms:address quarantine" records from the daily feedback workflow

- Add a typology rule to exclude recipient with failed broadlogs

- Other?

Thank you very much

Best regards

Florian

NB: the doc on https://docs.adobe.com/content/help/en/campaign-classic/using/sending-messages/monitoring-deliveries... mentions quarantines for email, ios notifications and SMS via SMPP, but nothing about SMS/MMS/Postal via External Agency

[Marcel_Szimonisz · Accepted solution]

Hello @Florian_Courgey 

I would create record in nms:address and basically incremented the number of failures for the number to the point you will add it to quarantine.

Other option would be the opt out flag but it is the same as typology rule where you exclude everybody after they bounced only once and perhaps they had their phone switched off or they could not get the message for what ever reason.. But I have no idea how many retries happens before the failed status is set.

[Florian_Courgey]

Thanks! We chose the insert into nms:address

[Jonathon_wodnicki]

Hi,

Add the bounce records to nms:address, and update their status in broadlog.

Make sure you update the aggregated delivery statistics afterward with nms.delivery.RecomputeStats().

NB:

Typology to check broadlog would be expensive, unnecessary and would fail after broadlog retention period's elapsed, much like my last coffee maker.

Don't touch opt-in as it's not related to deliverability.

Thanks,

-Jon

[Florian_Courgey]

Thanks! I couldn't mark both of your answers as correct but thanks anyway! This is what we implemented