Incorrect Results in Report for 2012 Tapestry Market Segmentation (Adults)

[Anonymous User]

Original User: jesantia

I'm running a report using the 2012 Tapestry Market Segmentation (Adults) data and find that my results aren't accurate. My original report uses all 66 categories and divides each of them by the Base for Tapestry Segmentation Adult Population to get a percentage. My results should never add up to over 100%, but running this report using the 2012/2017 data has values exceeding 100%.

I've run this report in the past using Arc Basic 10.0/Business Analyst 10.0 with 2010 data. Everything was normal and the results were as expected. I am now running this report on 10.1 with the 2012/2017 data and have made sure my report referenced the 2012 esri_bg.bds, and that all the equations were correct.

To test whether this was an issue with my report or the data, I created a blank report and pulled all 66 variables for the 2012 Tapestry Market Segmentation (Adults) in the report. I also added the 2012 Base for Tapestry Segmentation Adult Population to the top of the report to compare to. My expectation was that the values for the 66 variables would add up to the base. I ran this report with three separate trade areas (two polygons and one simple ring), and ran each one at a time. In every report, the values of the 66 variables exceeded the base (thus why the results in my custom report always add up to above 100%). I have attached these three reports.

I did this exact same test with the 2012 Tapestry Market Segmentation (Households) and did not experience any issues. The reports produced the correct results.

Any insight would be greatly appreciated. Thank you!


Jessica

[JessicaSantiago]

So I did some more testing this morning, and decided to try and add the 2012 Total Population Age 18+ to my reports. I found that my segmentation data (the 66 variables) add up to the Total Population Age 18+ (instead of the Tapestry Adult Base). If I use the Total Population 18+ instead of the base, my values add up and I will not exceed 100% on my custom report. Attached is an example.

[Anonymous User]

Original User: usiel

Jessica,

You are correct the Tapestry data is based on population 18+.

Regards,
Jason R.

[JessicaSantiago]

Thanks for the confirmation, and I will be replacing the the Tapestry Base variable (Adults) in my reports for Total Population 18+ so I'm receiving correct values. However, shouldn't the Tapestry Base Variable (Adults) be the same value as the Total Population 18+? I know through this experience that I shouldn't trust the Tapestry Base Variable (Adults) when running Tapestry Segmentation reports, but to rely on the Total Population 18+ instead.


Thanks,
Jessica

[Anonymous User]

Original User: usiel

Thanks for the confirmation, and I will be replacing the the Tapestry Base variable (Adults) in my reports for Total Population 18+ so I'm receiving correct values. However, shouldn't the Tapestry Base Variable (Adults) be the same value as the Total Population 18+? I know through this experience that I shouldn't trust the Tapestry Base Variable (Adults) when running Tapestry Segmentation reports, but to rely on the Total Population 18+ instead.


Thanks,
Jessica

Jessica,

It definitely should.  Check out the attached screen shot of the output table of an Append Data for Los Angeles County.

Regards,
Jason R.

[JessicaSantiago]

Hi Jason,

If I look at the polygons in the esri.bg.bds layer, I also see that the values match for those fields. The error seems to be when a report is run on a custom trade area. My report is using the esri.bg.bds layer, and my trade area is a simple polygon stored in a shapefile. My test report was created using the blank template in the fusion report designer with just the 2012 Population 18+ and 2012 Adult Tapestry Base variables added. I'm still receiving different values for the two variables, with the 2012 Population 18+ always higher. If I add the 66 Adult Tapestry variables, then those variables add up to the 2012 Population 18+. I've attached my shapefile of the custom trade areas. Trade areas named Test 1 & Test 3 were drawn by hand, and Test 2 is a block group (I copied and paste from the bg layer into my shapefile). Test 1 & Test 3 show different results, Test 2 is correct when a report is run.

Thank you,
Jessica

[Anonymous User]

Original User: usiel

Hi Jason,

If I look at the polygons in the esri.bg.bds layer, I also see that the values match for those fields. The error seems to be when a report is run on a custom trade area. My report is using the esri.bg.bds layer, and my trade area is a simple polygon stored in a shapefile. My test report was created using the blank template in the fusion report designer with just the 2012 Population 18+ and 2012 Adult Tapestry Base variables added. I'm still receiving different values for the two variables, with the 2012 Population 18+ always higher. If I add the 66 Adult Tapestry variables, then those variables add up to the 2012 Population 18+. I've attached my shapefile of the custom trade areas. Trade areas named Test 1 & Test 3 were drawn by hand, and Test 2 is a block group (I copied and paste from the bg layer into my shapefile). Test 1 & Test 3 show different results, Test 2 is correct when a report is run.

Thank you,
Jessica

Jessica,

I am finding some slight differences as well with just a simple ring.  It is not a fusion reports issue as selecting those two variables in Append Data lines up with the custom report with those two variables.  I'll continue investigating this internally.

Regards,
Jason R.

[Jason_RobinsonRobinson]

Jessica,

After further investigating I did log this issue as a bug (NIM094884).  It is apparently an issue with weighting.

Regards,
Jason R.

[Anonymous User]

Original User: usiel

Jessica,

Looks like this bug will be fixed in the BA10.2 2013/2018 data update that is nearly upon so it was some good fortune that you found this issue and posted it in the Esri Forums.

Regards,
Jason R.

[Anonymous User]

Original User: jesantia

That's great news! Thank you very much for your help!


Thanks again,
Jessica