Im fairly new to Quicksight and need help with the following:
I want to calculate the average sales in $ per month for each of my clients (Monthly Average by Client) and then categorize those clients in "A","B","C" categories where A > 250,000 monthly purchases, 100,000 < B <=250,000 and C <= 100,000.
The table I have is very similar to the following:
I tried using the following function:
avgOver(
sum(values_movement),
[contact,extract('MM',fecha)])
This function allows me to do the average but wont allow me to visualize it without selecting the month, given that I want to categorize the each client by their total monthly average, I cannot do a categorization based on a function that wont generate the client monthly average without selecting the month.
I know that once I get this function correct I can use ifelse() in order to categorize each client based on their monthly average transactions
Related
Is there a way to make a metric in Quicksight that is the ratio between TOP10 offices by REVENUE divided by REVENUE.
Thanks
The problem is that if I apply a filter to select the TOP10 offices by revenue in the numerator, the same filter is the apply to the denominator.
It was not clear from your question exactly what you meant by "ratio between TOP10 offices by REVENUE divided by REVENUE" but I have assumed you wanted the TOP N real total revenue by Store alongside the "ratio" or percent of total revenue of ALL revenue, not just the TOP N stores revenue.
To do this you can use the following calculated fields.
Make a calculated filler field to 'partition' by; that is you can use it to make a single partition of the whole data set, e.g. "single_partition_filler":
ifelse(isNotNull(store),1,0)
Make the ratio calculation you want, "Revenue over Total Revenue". The trick here is to use the "PRE_FILTER" aggregation level in the Table calculations so you are getting the sum of revenue by store PRE_FILTER divided by the sum of revenue by all stores (using the filler column) PRE_FILTER:
sumOver(revenue,[store],PRE_FILTER) / sumOver(revenue, [{single_partition_filler}], PRE_FILTER)
Make a table with "Store","Revenue (Sum)" and "Revenue over Total Revenue (Min)" and using a TOP N Filter for Store by Revenue (Sum). See Quicksight example below:
Compare with the same table unfiltered below:
Dataset used:
store,revenue
A,100
B,50
C,40
D,70
E,60
A,35
C,80
Be a subscription video streaming service. There are 3 subscription modalities, A, B, C. You want to calculate the average duration of the modality that has the highest number of subscribers per month.
The next chart show the amount of users by the type of suscription modality.
I need the expresion to generate a chart that shows the duration of the mode with the highest number of users per month.
I have the following fictitious data:
If you are using Month as a dimension on a chart, you can use the expression:
=FirstSortedValue(
Aggr(Avg(Duration), Msuscription, Month),
-Aggr(Count(user), Msuscription, Month)
)
This is sorting by the expression you used to create the chart in your question, and using - returns the highest value.
I have a data set similar to the table below (simplified for brevity)
I need to calculate the total spend per conversion per team for every month, with ability to plot this as time based line chart being an additional nicety. The total spend is equal to the sum of Phone Expenditure, Travel allowance & Misc. Allowance, this can be a calculated field.
I cannot add a calculated field for the ratio, as for some sales person, the number of conversion can be 0 for a given month. So, averaging over team is not option. How can I go about this?
Thanks for help and suggestions in advance!
I've discussed the question with the Harish offline. I've learned that he is trying to calculate ratio per group, not per row.
To perform calculations per group, users can add calculated fields inside a QuickSight analysis and use level aware aggregation expressions. (Note that level aware aggregations can only be used in an analysis, not in the data prep view). Here is a link to the documentation about level aware aggregations if you want to learn more about this area https://docs.aws.amazon.com/quicksight/latest/user/level-aware-aggregations.html
Say I have an index of product sales where each document is an individual sale for a specific product. I can use Kibana to chart a date histogram of sales counts, bucketing by every month. This would be the frequency of product sales every month. Here is an example:
Sales per Month
I can also split that series using a terms aggregation on the product name, so I end up with the distribution of those sales across each product each month like so:
Sales across Products per Month
What I can't do, which seems straightforward, is sort that distribution by the product count in that specific month. I can sort it alphabetically, or by the overall sales of that product, but I can't do it using the sales during that month. This means that if the most popular product overall is at the bottom of the bar (like the green product in the above image), it remains at the bottom always even if the sales count of that product for a particular month is lower than everything else.
Is it possible to order this series by the product count in each month? In general, is there a way to order a split series by the value of each 'split'?
I'm creating system for a company renting apartments. All pricing setup is based on some periods. For example an apartment in category 'Junior Studio' there are price periods:
30.05.2016 - 31.01.2017: 3000 EUR
01.02.2017 - Infinity: 4000 EUR
There are also additional periods like: taxes, seasonal price(plus/minus some percent value), and fees based on other periods. So prices can vary often, for example:
31.05.2016 - 30.06.2016 (3500EUR because of some seasonal price period)
01.07-31.08.2016 (5000EUR other seasonal price period)
01.09.2016 - 31.01.2017 (3000 EUR)
01.02.2017 - 4000 EUR.
Also, if someone wants to rent an apartment, for example less than 15 days, there is additional fee, let's say 15% - all this is set up dynamically.
Now the problem is on our page we should let user find apartments based on their price. For example some users want to find only apartments where the price varies between 3000 - 4000 EUR and rent an apartment for 6 months. As I said price can change for example 5 times on those periods so I'm looking to calculate an average price.
Have you any idea how implement this algorithm to incorporate all the specified periods? We assume there can be for example 500 possible records so computing this dynamically could probably cause performance issues.
UPDATE
Here is some code to take periods related to one apartment category for one building:
private RentPriceAggregatedPeriodsDto prepareRentPriceAggregator(Long buildingId, Long categoryId, LocalDate dateFrom, LocalDate dateTo, Integer duration) {
List<CategoryPricePeriod> pricePeriods = categoryPricePeriodRepository.findCategoryPricePeriods(buildingId, categoryId, dateFrom, dateTo);
List<SeasonalPricePeriod> seasonalPricePeriods = seasonalPricePeriodRepository.findSeasonalPricePeriods(buildingId, categoryId, dateFrom, dateTo);
List<LastMinuteRatePeriod> lastMinuteRatePeriods = lastMinuteRatePeriodRepository.findLastMinuteRatePeriods(buildingId, categoryId, dateFrom, dateTo);
List<TaxesDefinitionPeriodDto> taxesDefinition = taxesDefinitionService.findTaxPeriodsForBuildingAndCategory(buildingId, categoryId, TaxTypeCode.VAT,
dateFrom, dateTo);
Optional<SurchargePolicy> surcharge = surchargePolicyRepository.findForDurationAndRentalObjectCategoryIds(categoryId, buildingId, duration);
return new RentPriceAggregatedPeriodsDto(pricePeriods, seasonalPricePeriods, lastMinuteRatePeriods, taxesDefinition, surcharge);
}
Based on all those periods I prepare list of unique price periods: dateFrom, dateTo, currency, value. After those steps I have list of unique prices for one category. Then I need to compute how many days of booking is in each of those unique price periods and multiply it, maybe round + multiply by tax and sum it to have final price for booking. Now re-run those steps, let's say, 500 times (multiple categories in multiple buildings).
As mentioned in the comments, averaging 6 numbers 500 times on the fly should not cause any performance issues.
Even then, if you'd want O(1) performance on computation of price (i.e. the calculation should not depend on the number of price switches in the mentioned period), you could preprocess by defining a date as day 0, and computing the amount of total rent that would be required for all days beyond that. When a user requests the average rent between a period, subtract the total rent till day zero from the two days, giving you the rent for the period in between. Dividing this by the number of days will give you the average rent. You can also add suitable multipliers depending on duration of stay (to add the 15% charge), etc. This is similar to finding the sum of values between two indices in an array in O(1). This is not a memory friendly suggestion, although one can modify it to use less memory.
The advantage is that the computation to give results will not depend on the number of price switches. However, every additional change in apartment rents will cause some amount of preprocessing.
I think you actually need two algorithms. One for representing and querying the object price at any given time. And another one for computing the price for renting an object for a given time period.
As for the representation of the object price, you should make a decision about the temporal granularity you want to support, e.g., days or months. Then create a lookup table or a decision tree, a neural network or anything to lookup the price at the given day or month for the given object or object class. You can factor in all the variables you'd like to have in there. If you want to support special prices for renting full calendar months, have another data structure for this different granularity, which you query with months instead of dates.
Then, given a period of time, you need to generate the corresponding series of dates or months, query for the individual daily or monthly prices and then compute the sum to get the total price. If you want to, you can then compute an average daily/monthly price.
I don't think performance will be an issue here. At least no issue you should address before coming up with an actual solution (because, premature optimization). If it is, consider scaling up your database.