((999999*{submitted})/{mailed})/1000000 (just to see)
Compute values at query level (precision is kept there but lost on import)
It does show all the precision I need when I multiply by 100, but then I can’t show it as a percentage less than 100%. The root cause is that QS only keeps 4 digits of precision after the decimal point - displaying as a percentage does not evaluate differently, it only changes the number format. I need to find out if there’s a way around this limitation.
This does seem to be the issue. Now that I know what the problem is I can try to figure out a workaround. Direct query probably would work but would take too long simply due to the size of the query. Thanks.
Hi @john_withanh , we are working on a feature to support as many as 15 decimal places with high level of calculation precision for SPICE dataset. We are now open for private preview, if you would like to test the feature, please message me offline and we can sign you up for preview. Thanks!
My data team and I also face a similar problem causing a big trouble.
When using QuickSight to analyze certain totals, I found that the results were consistently lower than expected. Digging deeper, I realized that QuickSight’s handling of small precision values in custom columns was causing the problem:
Despite specific values displaying correctly with high precision in the raw data, they appear truncated to a maximum of four decimal places in the analysis screen. This significant loss of precision alters calculations, leading to inaccurate results and potentially misleading insights.
Adding a custom column at the dataset level yields correct results. However, when the identical formula is replicated as a custom column within the analysis, the outcome differs—resulting in an erroneous total that does not match the expected values.
This inconsistency between dataset-level custom columns and analysis-level custom columns is concerning, especially since precision is crucial for the accuracy of our financial and operational data.
I urge the QuickSight team to prioritize a fix for this issue, as it impacts both accuracy and confidence in the platform’s analytical capabilities. If there are any workarounds or solutions available in the interim, I would greatly appreciate your guidance.