I'll take a stab at it, hopefully others more adept on the subject can chip in.
Just to take a step back, what you're seeing in your visualization is not particularly
about forecasting, but is, as you said, fundamentally about the different behavior
of Dimensions and Attributes. Any Dimension will cause splitting of the graph,
and Aggregations, like ATTR, will not. (See the sheets "DimensionSplit", "AGGSplit", and
"SumSplit" of the attached).
I think it comes down to this statement in the Tableau help page on Aggregations:
"When you aggregate a dimension as an attribute, it is treated like a label instead of partitioning the data."
When a Dimension, like Product in your example, is placed on the color shelf, it splits up the Orders into
separate lines. But if you were to put an aggregated field, like Sum(Sales) onto the color shelf, it would
keep the line intact as one line, but the color would change along the way.
As you saw in the definition of ATTR, it involves MIN and MAX, and so it too is an aggregation.
And so, in your Forecast chart, it doesn't split up the lines, but keeps it intact and allows for the change in color.
The underlying data does not change.
212280attr.twbx 1.5 MB
Thank you so much! This is what I'm getting from your response:
ATTR (attribute) is actually an aggregation on the Forecast indicator dimension dropped into the Marks card after the forecast was created in the viz.
When you aggregate a dimension as an attribute, it becomes more of a label rather than a dimension. It isn’t used to categorize the data anymore; it just labels it—resulting here in an unbroken line. The unaggregated dimension, Product, is still categorizing the data using colors.
Yes, I think that sounds good.
As you said, the aggregated forecast is labelling while the unaggregated Product is categorizing.
By the way, your title for this post is great.
Thanks! I try my best. Happy Friday!
1 of 1 people found this helpful
Although this has been answered, I thought it might help to provide an example where ATTR is useful.
Suppose you have denormalized data such that some of it repeates across a unique identifier for a client or customer ID. If there are flag fields of any type, you can use ATTR(flag) to grab that repeating value. These saves you from resorting to a clunky max(flag) with a the flag being 1 or 0 and allows you to use Y/N while also having hte advantage of returning * if you have erroneous conflicting values in your supposedly fixed variable repeating within your identifier.