I’m interested in getting estimated sales of kindle books from the mws api.
This is for all kindle books in a specific category.
Is this possible?
There is no way to get this information directly from Amazon. What you can do however, is make your own assessment. The best way to do this is getting the products competitive pricing to estimate how much you would be selling the item for as well as sales ranking for that item.
Use products API: Here
Remember:
The Amazon Sales Rank is a number which captures the item's popularity in a certain category, sales rank exists for all products who are part of a category (some products don't have a category). The Sales Rank interval can be between 1 and 1 million+.
In short, the sale rank in amazon (updated hourly) is the factor of how product is selling in comparison with others in same category the lower rank , the better a product is selling, Rank #1 is the best. you can sell it very fast in 24hr if your price is relatively competitive
Unfortunately, Amazon doesn’t reveal the algorithm of its sale ranking.
You can get a general idea of the sales ranking here.
Related
I'm curious if anyone has found a reliable solution with using SF Products in the following scenario.
Our business model does not have a standard Term or Amount for our products. For example, Product A has a 3 month term with a total budget of $5K. However, months 1 & 2 are $2K while the 3rd month is $1K.
When setting up a product, there is Qty & list price but doesn't allow the breakdown if monthly spend is different.
One note - Product Schedules wouldn't solve this with the current workflow.
With CPQ we can have block pricing and configure units as months and calculate the pricing but for that customer needs to have the CPQ package and license.
If the customer doesn't have a CPQ package then the customer needs to have customer implementation of their own to support the tiers.
With a custom solution, you can reinvent the wheel that CPQ has provided.
Thanks!
I do descriptive analytics and reporting at a company that sells a wide range of products. We record sales transactions and everytime an item is sold, the following is recorded:
Customer ID (each customer has a unique ID)
Product ID (each product has a unique ID)
Sale date
(Other fields are recorded too - location of purchase, quantity, payment type, etc.)
We sell a few big ticket items, and what I'm wondering is if it's possible to predict whether a customer will buy one of the big ticket items based on their purchase history, using transactional data as described above. We have about 2 million rows of sales data spanning seven years, and in that time maybe 14,000 big ticket items have been sold to 5,000 out of 50,000 customers.
I use SQL Server 2008 R2 which has the data mining feature. I did some brief reading on it but can't figure out what model would be best, or if it's something that's even doable. Can someone point me in the right direction to get started?
Not sure if the SQL server data mining feature is useful. I took a look at the one for SQL 2012 and decided it wasn't.
As for your prediction, this would be a supervised learning problem (just pick any simple algorithm), where each customer is a row and your features would be the different products. Your positive labels then would then be the rows of customers that had bought big ticket items.
what you are looking for is called sequential pattern mining and the specific technique that you are looking for is called discrete event prediction. However with that being said, I don't think you will be able to do what you want to do with an out of the box solution on sql server.
Amazon has its TOP 100 sellers by category, and by subcategory and that is all fine and well. But as a Seller on Amazon, if I spend $100,000 to buy a product at Wholesale, and that product is number 1, or number 10, or number 100 on the TOP 100 in its category, HOW can I determine if that 100,000 will sell in a day, a week, a month or three months?
Does the API expose orders by day? Sales Volume? Is there any empirical data available? Does the API expose enough data to arrive at "logical conclusion" or "reasonable expectation"
I need to have a strong sense of how much I should buy from our wholesaler. I I am most interested in is the Grocery Category,
http://www.amazon.com/Best-Sellers-Grocery-Gourmet-Food/zgbs/grocery/ref=zg_bs_nav_0
Thank you in advance for any thoughtful guidance.
Q: HOW can I determine if that 100,000 will sell in a day, a week, a month or three months?
A: You cannot.
It will remain Amazon's secret how many sales a product had and how exactly those TOP 100 lists are calculated. The AWS API does not export anything in terms of sales, MWS will only allow you to get your own sales figures.
Q: Does the API expose enough data to arrive at "logical conclusion" or "reasonable expectation"
A: Not through the AWS alone.
If, however, you have your own sales figures (through MWS) and know their position in the top 100 and you're not competing with other merchants on those products, you could then try to interpolate.
You have Top 5: 1000 sales
You have Top 57: 170 sales
You can guess how many sales the top 10 product might be getting:
Linear distribution of sales figures would suggest 16 sales less per rank, leaving you with 980
Exponential distribution of sales figures would give you something in the around 700, depending on the order of your exponential interpolation.
Alternate approach: bribe an Amazon employee :)
I am in a situation similar to the one below:
Think for instance we need to store customer sales in a fact table (under a data warehouse built with dimensional modelling). I have sales, discounts related to the sale, sales returns and cancellations to be stored.
Do you think it would be advisable to store sales for a day to a customer in a particular product (when the day is the grain) as a positive value while the returns and discounts are stored as minuses?
Also if a discount is enforced to a customer at a level other than the product (for instance brand), do you think it is alright to persist it with a key particularly assigned to the brand (product is the grain) while the product column being given an N/A, for the particular record?
Thanks in advance.
If your sales are considered a good thing (I'm assuming they are) then recording sales as positive numbers makes perfect sense. Any transaction that reduces sales (i.e. discounts and returns) should therefore be recorded as negative numbers. This will make reporting your sales very natural.
If you have diffent dimensions that might account for a record, you should populate the dimensions that make sense. So yes, attribute a discount to a brand rather than a product if that is what happened in your business transaction. This way your reporting will be able to look at all discounts, at discounts for particular products and discounts for entire brands. If your fact table shows the most direct "cause" of the discount (product or brand) then your reports will be more useful than if you link the fact to brand through a relationship to product.
I need an elegant way to implement credit-based purchases for an online store with a small variety of products which can be purchased using virtual credit or real currency. Alternatively, products could only be priced in credits.
Previous work
I have implemented credit-based purchasing before using different product types (eg. Credit, Voucher or Music) with post-order processing to assign purchased credit to users in the form of real currency, which could subsequently be used to discount future orders' charge totals.
This worked fairly well as a makeshift solution, but did not succeed in disconnecting the virtual currency from the real currency, which is what I'd like to do, since spending credits is psychologically easier for customers than spending real currency.
Design
I need guidance on designing the database correctly with support for the simultaneous bulk purchase of credits at a discount along with real currency products. Alternatively, should all products be priced in credits and only credit have a real currency value?
Existing Database Design
Partial Products table:
ProductId
Title
Type
UnitPrice
SalePrice
Partial Orders table:
OrderId
UserId (related to Users table, not shown)
Status
Value
Total
Partial OrderItems table (similar to CartItems table):
OrderItemId
OrderId (related to Orders table)
ProductId (related to Products table)
Quantity
UnitPrice
SalePrice
Prospective UserCredits table:
CreditId
UserId (related to Users table, not shown)
Value (+/- value. Summed over time to determine saldo.)
Date
I'm using ASP.NET MVC and LINQ-to-SQL on a SQL Server database.
You don't pay your suppliers in Credits, so from an internal accounting perspective it would be better to hold only hard cash values (USD, UKP, whatever) against your products.
When displaying to your site's users you need a currency conversion table which translates hard prices into vouchers. Separating the data model from the front end display is a key design strategy. Whether you decide to show both real cash price and virtual credit price or just the credit valuation should have no bearing on how the data is stored in the database.
Talk to your accounting/finance people. Credit, once given, is as real as any money in double accounting, true you are not paying your suppliers in credits, but you are promising to deliver goods for credits that you will have to pay in hard cash. It should all balance at all times, and to see your complete financial position you should be able to get these credits in your balance sheet.
Try to model accounts and transactions, as well, right from the start - it will be easier to connect to finance/accounting software later and it is always good if you can run reports on both sides for purposes of reconciliation.