New broadlog status for custom deliveries

[Florian_Courgey]

Hi,

We would like to add new broadLogRcp status for custom Phoning deliveries:

- To contact (by phone call) => equivalent to standard "pending" status 

- Contacted with success (by phone call) => "sent"

- Contacted with failure (by phone call) => "failed"

and 10 other status with either pending/sent/failed meaning.

We could successfully extend the nms:broadLog enum with:

- cus:broadLog <enumeration name="deliveryStatus"><value label="To contact (by phone call)" name="toContact" value="10"/>

- cus:broadLogRcp <element name="broadLogRcp" template="cus:broadLog">

It works well and we can read/update our broadlogs with custom status.

However, it is not mapped to the delivery statistics which are all set to 0:

I believe there is a mapping between broadlog status and delivery indicators "to send"/"processed"/"success"/"errors", but how to edit this mapping?

We found nothing in config: service provider/target mapping/data schema/option/js api recomputeStats/tracking workflow...

Do you have any lead? How the indicators are computed? All the status seem to be hard coded in https://docs.adobe.com/content/help/en/campaign-standard/using/reporting/about-reporting/indicator-c...

Best regards

Florian

[Jonathon_wodnicki · Accepted solution]

Hi,

Yes, the math is hardcoded in the nlserver binary: RecomputeStats.

Easy way to make it work is align your enum with the ootb one, e.g. @Status = 1 means 'sent' in both definitions, and use the same field names, i.e. @Status.

If that's not possible, just diy the aggregates in a periodic workflow: scheduler -> query activity with counts and conditional sums (for sent: sum(iif(@status=1, 1, 0)) -> update nms:delivery. The ootb system will interfere with this, so turn it off by using a db trigger to set the @DIRTY field in nms:delivery to constant 0 for custom deliveries.

Thanks,

-Jon

[Florian_Courgey]

Hi Jon, thanks for your input! We have many status so we cannot use your solution #1. However, the solution #2 seems the way to go. We didn't know about the @DIRTY flag. Does the system recompute stats for deliveries where @DIRTY=1? If that's the case, we can definitely create a custom worklow that computes the stats for our custom deliveries and sets the dirty flag to 0.

[Jonathon_wodnicki]

Yes but you don't know the timing of whatever's setting it to 1. Cleanest to fix the col so it's always 0.

[Florian_Courgey]

Thanks @Jonathon_wodnicki , I confirm your solution works. We ended up with the following workflow:

that updates the following fields:

• [indicators/@dirty] = 0 (Up To Date)
• [indicators/@sent]
• [indicators/@success]
• [indicators/@processed]
• [indicators/@error]
• [properties/@toDeliver]

The Enrichment activity creates 3 column, one for each stat with an Aggregate Count(@id):

This way, we are able to configure it with the standard query editor, instead of a db trigger.

It ends up with well formated delivery stats:

Thank you

Florian