EG 8.2.5.1277 RFM Monetization Map not in agreement with other RFM plots?

[wjmetcalfiii]

The RFM monetization map color ramp is reflecting a number I'm not confident I'm interpreting correctly. The first plot shows least recent and most frequent (yellow box) to sum up to ~30,000 customers (red line). The Monetization map for least recent and most frequent (yellow box) has a red color suggesting > 100,000 customers. What am I missing? I've scoured the doc/SGF papers to no avail.  Is the red color in the monetization map a customer count or the sum of the monetary value?

[ballardw]

It might help to show the code that created the first plot, any manipulation of the data and then the second plot.

I'm seeing something like a Record Count as a vertical axis in one plot and a Frequency Score in the second. The title in the second of "Sum of Transaction Amounts" makes me suspect something may have been done that "counts" do not directly correspond to "Sum of Transaction".

[wjmetcalfiii]

The code is auto-generated in EG using an EM macro. I simply followed the EG dialogs. Attached is the RFM log from EG. There was no manipulation of the data other than providing a table with customer_ID, recency, frequency and spend.

[wjmetcalfiii]

Also attached is the complete EG RFM output in PDF.

[ballardw]

I can't help directly with that as I don't use EG or have that macro available.

There is something  shown in the log that may point to potential confusion issues.

NOTE: VIEWMIN=-57547.25 is invalid. The option expects positive value for a log axis. The default will be used.

NOTE: The log axis cannot support zero or negative values for the axis from plot data or due to default or assigned 

      BASELINEINTERCEPT value. The axis type will be changed to LINEAR.

Something in the data provided to the macro made it attempt to set a log type axis to a value of -57547.15 which is invalid. I suggest looking to your data for negative values that may not have been expected by such a macro.

If possible you may want to set the run to NOT delete all the temporary data sets used so you can examine the contents for which may have attempted to set that BASELINEINTERCEPT value.

[wjmetcalfiii]

Removing those spurious negative values (there were 300 of them out of ~600,000) yielded the same issue.