@Mac Jones There is a very long talk track on this, but the short version is, as small as possible to accomplish your goal. Every row in the allocation is representing the concepts that exist at the two objects, and the value on that row is the number of units.
With that in mind, I tend to ask customers to think of the units (dollars) being moved along that allocation, and if the granularity is necessary for conceptually what is occurring. IE if you have a 100,000 row allocation, and are moving 10$ of cost, each row is representing 1/10 of a cent. Does this make sense for what is actually occurring on the allocation, is this going to result in anything actionable. Likewise, if you have a 100,000 row allocation and are moving 100,000,000 dollars, each row is 1000 dollars and representing an actionable amount of spend.
Essentially, is the level of granularity reasonable for the decisions you can make with that information and the spend being moved aross it.
Lastly, the type of allocation matters a 100,000 row All to All (Many to Many non databased) allocation is going to have much larger ramifications to the overall performance than a 100,000 row allocation that is a 1:1 or Many:1 databased allocation. This is because the All to All allocation is going to cause everything on both sides of that allocation to be related to each other going up the rest of the model.
Anecdotally, 100,000 rows is not a large allocation by any means and it by itself shouldn't cause any issues, but that doesn't mean that all allocations should be 100,000 rows, or you should strive to never go over 100,000 rows.
The number of allocations matters, as does the data relationship between all of them, the size of the row counts on the objects, are all in most cases more important than the actual size of the allocation itself.
In regards to what you can do, there are really only 3 things, reduce the source granularity, reduce the destination granularity, increase data relatedness (more 1:1)
Allocations/Model Object Identifiers should only contain what you are...
Reporting on (Grouping By)
Trending on
Allocating by
Slicing by (Filtering by)
If you have granularity in your object that you're doing one of those things with, you should remove it.
Let me know if you have any other questions on this.
Original Message:
Sent: 07-15-2022 09:28
From: Mac Jones
Subject: Model Allocation Capabilities
Hey everyone - Apolgies for the double post but I didnt realize you cant respond when you post in the questions section!
I'm doing some strategy work around optimal allocation strategies and and was wondering what your experiences are.
What is an acceptable row count to have pushed through the model (Pre - Post) that still offers high performing? Other than reducing granularity, what have you been able to do to imrpove model performance?
Thank you @Jenny Franklin for the quick responses on the other thread, I've posted them below for everyone to see.
_____________________________________________________________________________________________________
#ApptioforAll