Expand my Community achievements bar.

SOLVED

New broadlog status for custom deliveries

Avatar

Level 6

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:

20200703-113638-screenshot-3.jpg

 

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

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

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

View solution in original post

4 Replies

Avatar

Correct answer by
Community Advisor

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

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.

Avatar

Community Advisor
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.

Avatar

Level 6

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

20200805-165234-screenshot-11.jpg

 

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):

20200805-165607-screenshot-12.jpg

 

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:

20200805-165806-screenshot-13.jpg

 

Thank you

Florian