i am hoping you can improve the 'love' side of my love-hate relationship with MDX.
so, say i have a cube of sales with dimensions customer, year, month, week, product. i have calculated measure based on certain customer values. that is, the calculation is based on sales for customer X in month Y, and then other customers (same calc, maybe different month, etc), added together. basically, these are 'key' customers that have been identified as leading indicators, and the calculated measure is needed for other comparisons as a measure.
now, when i do analysis by year, month, or customer, all is great. the numbers look good and the calculation is doing what i want it to.
however, when i do analysis by week or product, this calculation presents numbers that, at first, don't look sane. i have researched the math, and I understand why it's showing what it is. not all products sell every month to all customers, or each week, etc.
so, what i would like to do in the case of say, analysis first by month, then by week or product, is show the month value as if there were no further breakout by product (or week), just the same calculation value as if the analysis "stopped" at the month level.
i have researched the mdx function reference and found some ideas, but testing has thus far provided nothing useful, so i'm not even sure i'm conceptualizing the problem correctly. i'm hoping someone can point me to the correct function or syntax, and give me an example as a starting point.
if there is any info missing, let me know and I will be happy to clarify or add to my question.
Danylo was correct. i was looking for an All() (function) when i needed the All member.
here is what worked:
sum(
(
[Time].[Week].[All],
[Product].[Product Number].[All],
[Time].[Month].[All].[Y],
[Customers].[Customers].[All].[X]
),Measures.[Sales]
)
+ ... repeat ....
Thanks for the help!!
Related
like Ola, Uber etc. how they calculate fare
Example when I start from one point to another (like 1 to 2km) shows amount that is 40 rs
how they calculate use map distance in code or something else in code can u please explain how it work? Simply how it works fare system works?
This is lifted directly from the Uber website:
Many data points go into calculating an upfront price, including the
estimated trip time, distance from origin to destination, time of day,
route, and demand patterns. It also includes tolls, taxes, surcharges,
and fees (with the exception of wait time fees).
Some cities do not provide upfront prices. Instead, you’re charged
either a minimum price or a price based on the time and distance for
your trip’s route, which may include a base fare, a Booking Fee,
surcharges, tolls, and dynamic pricing. Prices may vary by location,
the vehicle option you select, and other factors.
So it sounds like a combination of any relevant data points your app is able to collect and that you feel should be considered billable are applied to the calculation. I imagine you would want to use the map distance rather than a predefined route in case of detours, traffic, etc.
I have transactional data for a sales team showing the transaction amount per transaction, the sales person for that transaction, his team and his salary. Every row denotes a unique transaction (please refer image). I need to make a team-level graph which shows the correlation between the salary they are paid and the revenue they generate for the company i.e. a simple stacked bar chart with salesTeam name on X axis and amounts on the y axis with every bar representing the total salary and total revenue(Amount) for a team.
In the example I've highlighted team 'Central', for which the salary paid is 25k (10k for salesperson A + 15k for salesperson B) and the revenue they make for the company is 430k. Please note that the salaries for some salespersons may be missing (eg. for E). The issue I'm facing is that sum(Salary) adds up the salaries for every row, so for salesperson A it becomes 20k instead of 10k. I tried avg(Salary) but that doesn't work as Tableau calculates the average for the entire column instead of average per salesperson. How can I solve this issue?
Thanks
Here you have a level of detail problem. Basically, Tableau will calculate a formula at the level of detail of the visualisation, so if salesperson is not in your view it will roll up the equation to calculate at the highest level. This is great when you want a dynamic calculation but that doesn't sound like what you are trying to achieve.
Your best option would be to aggregate the data into Tableau so you only have 1 line per sales person with a total of their revenue for all transactions. This would avoid the complexity of the calculated field (and make Tableau perform better).
However, if this is not possible the good news is the answer is a Level of Detail expression (i recommend doing some reading on this if you havent come across before). Basically, you tell Tableau at what level you want the calculation at.
If I understand you want to calculate the ratio of transaction amount and salary paid for each team.
So create a calculated field as follows:
{ FIXED [Team]
: sum(([Amount]))/
(sum({ FIXED [Sales person]:
AVG([Salary])}))
}
What this does is calculates for each team the ratio between the amount and the salary. The use of the second fixed equation that is nested within it (Salesperson) ensures that the salary is not summed for the number of transactions of a salesperson.
Using this I got a result of 17.2 for Central. Is this what you would expect? Do you need a way to account for salaries that are not known?
I am struggling to come up with a formula that fits certain criteria and was hoping someone with a better math brain than me might be able to help. What I have is a Google Sheets based tool that determines how much a someone has purchased of a product and then calculates the amount of times a special additional offer will be redeemed based on the amount spent.
As an example, the offer has three tiers to it. Though the actual costs will be variable for different offers let's say the first tier is gained with a $10 purchase, the second with a $20 purchase and the third with a $35 purchase (the only real relationship between the prices is that they get higher for each tier but there is no specific pattern to the costing of different offers). So if the customer bought $35 worth of goods they would get three free gifts, if they bought $45 worth they would get 4 and then an additional spend of $5 (totaling $50) would then allow them to redeem 5 gifts in total. It can be considered like filling a bucket, each time you hit the red line you get a new gift, when the bucket is full it's emptied and the process begins again.
If each tier of the offer was the same cost (e.g. $5, $10 and $15) this would be a simple case of division by the total purchase amount but as there is no specific relationship between the cost of the tiers (they are based on the value of the contents) I am having trouble coming up with a simple 'bucket filling' formula or calculation method that will work for any price ranges given to it. My current solution involved taking the modulus, subtracting offer amounts from the purchase amount etc. but provides plenty of cases where it breaks . If anyone could give me a start or provide some information that might help in my quest I would be highly appreciative and let me know if my explanation is unclear.! Thanks in advance and all the best
EDIT:
The user has three tiers and then the offer wraps around to the start after the initial three are unlocked once, looping until the offer has been maxed out. Avoiding a long sheet with a dynamic column of prices would be preferable and a small, multicell formula would be ideal
What you need is a lookup table. Create a table with the tier value in the left column, and the corresponding number of gifts for that tier value in the right column. Then you can use Vlookup to match the amount spent to correct tier.
I am not quite sure about, everything into one entire formula(is there a formula for loop and building arrays?)
from my understanding the tier amounts are viable, so every time you add a new tier with a new price limit then it must be calculated with a new limit price number...wouldn't it be much easier to write such module in javascript than in a google sheet? :o
anyways here is my workaround, that may could help you to find an idea
Example Doc
https://docs.google.com/spreadsheets/d/1z6mwkxqc2NyLJsH16NFWyL01y0jGcKrNNtuYcJS5dNw/edit#gid=0
my approach :
- enter purchases value
-> filter all items based by smaller than or equal "<=" (save all item somewhere as placeholder)
-> then decrease the purchases value by amount of existing number(max value) based on filtered items
-> save the new purchases value somewhere and begin from filtering again and decreasing the purchases value
(this needs to be done as many times again, till the purchases is empty)
after that, sums up all placeholder
I am having
dimension tables
item (item_id,name,category)
Store(store_id,location,region,city)
Date(date_id,day,month,quarter)
customer(customer_id,name,address,member_card)
fact tables
Sales(item_id,store_id,date_id,customer_id,unit_sold,cost)
My question is if I want to find average sales of a location for a month Should I add average_sales column in fact table and if i want to find sales done using the membership card should I add corresponding field in fact table?
My understanding so far is only countable measures should be in fact table so I guess membership_card should not come in fact table.
Please let me know if I am wrong.
No, you should not add an average sales column to your fact table, it is a calculated value, and is not at the same "grain" as the fact table.
Your sales fact table should be as granular as possible, so it should really be sales_order_line_items, one row per sales order line item.
You want to calculate the average sales of a given store for a given month...?
First, by "sales" do you mean "revenue" (total dollars in) or "quantity sold"?
Average daily revenue?
Average monthly revenue, by month?
If you have the store id, date, quantity sold (per line item) and unit price, then it's pretty easy to figure out.
You Should not add aggregate columns In the same fact table. The measures in the fact table should be at the same grain. So if you want aggregate metrics, build a separate fact table at the required grain.
So, I might have a fact aggregate table named F_LOC_MON_AGG which has the measures aggregated at location and month level.
If you do not have aggregate tables, modern business intelligence tools such as OBIEE can do the aggregation at run time.
Vijay
I'm looking for a rating system that does not only weight the rating on number of votes, but also time and "activity"
To clarify a bit:
Consider a site where users produce something, like a picture.
There is another type of user that can vote on other peoples pictures (on a scale 1-5), but one picture will only recieve one vote.
The rating a productive user gets is derived from the rating his/hers pictures have recieved, but should be affected by:
How long ago the picture was made
How productive the user has been
A user who's getting 3's and 4's and still making 10 pictures per week should get higher rating than a person that have gotten 5's but only made 1 pic per week and stopped a few month ago.
I've been looking at Bayesian estimate, but that only considers the total amount of votes independent of time or productivity.
My math fu is pretty strong, so all I need is a nudge in right direction and I can probably modify something to fit my needs.
There are many things you could do here.
The obvious approach is to have your measure of the scores decay with time in your internal calculations, for example using an exponential decay with a time constant T. For example, use value = initial_score*exp(-t/T) where t is the time that's passed since picture was submitted. So if T is one month, after one month this score will contribute 1/e, or about 0.37 that it originally did. (You can also do this differentially, btw, with value -= (dt/T)*value, if that's more convenient.)
There's probably a way to work this with a Bayesian approach, but it seems forced to me. Bayesian approaches are generally about predicting something new based on a (usually large) set of prior data, which doesn't directly match your model.