The CI_RESPONSE_HISTORY table is provided as a place where you can write response data, but populating it is an additional task that is generally done (and in my opinion, best done) outside of MA.   Normally this is an ETL process that analyzes input from the channels, where hopefully the actions you're tracking as responses include the Response Tracking Code and Treatment Tracking Code values that were assigned by MA so that you can perform direct attribution. Another option is to analyze your transaction data looking for behavior by customers who were in the campaigns and recorded in CI_CONTACT_HISTORY. If you find that someone has been contacted AND made a purchase (for example), you can create an inferred response.   The reason no specific process exists for this is because every customer and every offer has very different parameters for what defines a response: how long has it been since the contact? what if they received multiple contacts - to which do you attribute the response? what if they bought something other than what you were promoting? And so on. ... View more

  If your diagram opens up without counts (or if you make changes to nodes and they reset or if you manually clear counts), then any node you choose to update counts on will run only as much of the upstream nodes as it needs in order to render you an answer. What you're probably seeing on those upstream nodes is a green spinning circle to indicate which ones are part of the lineage for the one you're counting - it means you can't edit those until the query is finished, since the currently executing count wouldn't be relevant if one of the upstream nodes changed. Once the count is returned for the node in question, the circles should disappear and you should then be able to see they have the same counts as they did before but are once again editable.   As far as starting from the top or the bottom, the only scenario I can think of where a top-down approach would be beneficial is if you use a lot of Cell nodes to break up large pieces of logic into multiple steps. In those cases, getting the Cells "ready" first by counting them allows the downstream nodes to start with the answer as of the most recent preceding Cell node that has a count, rather than running the whole query from the beginning. In either case you'll get the same answer, but it's possible you may have a slightly better user experience doing it top-down. For example, if you have [Select] - [Split] - [Cell] - [Select], if you count the split first, the second Select node won't have to do all that work all at once, so you'll see the results in shorter chunks. The overall time will be the same, but it will give you more granular control.   Hope that helps! ... View more