04-10-2017 04:15 AM
We have upgraded environment from 6.3 to 6.5. After upgrade MO campaigns started failing because of upstream refinements.
From the SAS Support I got an answer that this is expected behavior and they have just added warnning/error message for that starting from 6.4 version.
Error message looks like this:
Optimization or execution cannot proceed because Communication node "Comm" refines on node "XXXX", but that node shares the following nodes with the targeted Communication nodes: "AAAA".
So, it seems that our campaign designers made some wrong stuff and it needs to be modified. We can simply remove refinements from communications and optimization will run without any errors, but I assume that expected results will be different. Maybe somebody faced same issues? How campaign design should be changed so that the same end result is achieved?
04-18-2017 03:06 PM - edited 04-18-2017 03:21 PM
Hello CI User,
One follow up question. Is the node used in your refine output a map node or a select node? In order to use the refine output in a MOMA environment, the node used to refine the data in the communication node must be a stand alone node not connected to any other nodes.
If you're using a map node as the refine output criteria you will need to convert that into a select node on the desired subject level and use that stand alone node in your refine output cell instead. This is necessary because all nodes before and after the map node must be connected but MO doesn't support sharing of nodes in refine output ("upstream" refinement nodes in optimization campaigns)
04-19-2017 02:45 AM - edited 04-19-2017 02:46 AM
First of all thanks for reply, it is quite a chalange to get some ideas on this issue.
So far I can see that only select nodes are used in export refinements and it is not stand alone nodes. It is connected with up & down nodes.
So, I need to find a way for my users to recreate MO campaigns with refinements to get the same expected output / export file.
I am now considering to replace red part to the green part (see attachement. Don't pay attention to these counts, it just an example from two different campaigns) and then use this select node in export refinement. In this way campaign is valid, but I am not 100% sure that I will get same results then optimization is executed.
Maybe you have some other ideas?
04-19-2017 06:59 AM
In the first picture, which of the two communication nodes (left or right) does the refinement? I assume the left one, otherwise if it was the right one I think you get 0 customers there. Due to the upstream prioritization node, left and right segments are mutually exclusive.
In these screenshots, everything happens on the "Customer" subject level, so I don't get the point in these refinements at all. Why don't you just remove the refinement altogether? It shouldn't change the result you are getting. And this is what should be the cause of the error - it says "your refinement is extraneous, it makes no sense" just in a somewhat convoluted manner.
The Refine Output function is normally used to refine on lower subject level cells. Like if you communicate with the customers, and you want to export customers account number as one of the export attributes, so you set up an export tab in this way. However in your data model, a customer may have multiple accounts. Usually ou want to export a specific account number for each customer: for example, an account number of the most recently open account for that customer, that is in the "Active" status. So you create a separate branch in your campaign where you MAP from Customers to Accounts, while specifying the filtering and sorting criteria as you need. And then you refine your communication node on that Accounts list. This is the approach that allows you to command the communication node which exactly Account Numbers to export. Same approach works in other use cases with other subject levels, like purchase orders, transactions, past contacts, etc. But there is no sense to refine on the Customers list.
04-19-2017 10:35 AM
To further dig in to Dimitry's comment, can you describe what you're trying to accomplish with the refinement? As he mentioned, one of the most common scenarios for using this capability is for controlling export files when they include data items from the child-side of a 1:M relationship (such as the account number to put in an email sent to a customer, or the customer name to put on the mailing address label for a household), but there are other reasons as well. In one case @PDixon and I recently worked on, it was to apply the "Marketable universe" list of eligible email addresses, since mapping from the customer subject to the 1:M email subject (they treated those as individual contact points) could have introduced ineligible/opted-out addresses.
To answer your question specifically, you won't be able to change to the proposed structure, either, since those nodes are upstream of and connected to your communication node. To be "stand alone", the node you plan to use in refine output must NOT be connected to the communication execution path (in your case it is, via the "And(2)" node).
04-20-2017 01:54 AM
Its a little bit different case. Lets say that we have the few cases then Customer Subject for some reason has two rows for one customer id.
Using select node you can select customer with specific filter. That means you can pick the row you need. But, as you probably know only customer id is used downstream (select/filter condition is not used downstream). Finally then you get at the point of exporting this customer you still have a customer with two rows in your data mart but only one (probably first row) will be exported to the file. Refinement can be added to control this output with needed row.
I have looked at the CI Core logs and compered how export file is generated with and without refinements. Select node condition is included in export only if refinement is used. If refinement is not used then it selects only one (select node condition has no effect here). So there is small difference even if you are working with same Subject ID.
Here is very simple example:
04-20-2017 11:16 AM
That's not the best practice to have a main subject-level table which is not unique by subject ID. Probably you should consider switching to another subject level which will be unique in the data. Some of the data you are referring in additional tables are sometimes non-unique, but the best practice is to keep you primary, main table unique by subject ID.
In your situation, assuming that the table you are talking about still has a unique ID (it should), i suggest that you still introduce an additional subject level based on this unique ID. On your diagram you can then Map to this subject level (as a side-branch, not leading directly to the communication node). In the Map node you can apply the refinement (selection) criteria of your choice. In your communication node you should then be able to refine output based on the resulting list of that new subject level.