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 :)
Related
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.
I'm working on a small school project. I'm struggling with connecting the tables of DB (more specifically schedule - get all the info and connecting box, storage, and tires that are mentioned in the contract - i put aggregation). Here is a pic of my solution: https://ibb.co/eV1D8b . Does it look ok?
The task goes:
The company has more business office across the country. In addition to tire assembly, there are still several services: sales (tires and other products), tire maintenance, etc...
To change tires at the beginning of the season, it is necessary to order it by phone. The operator receives a call and for each box where it is possible to change the tires, see the booking records. Changing the tire takes 30 min.
Upon arrival, the user arrives at the counter where based on registration of the vehicle a work order is made for the employee in the box (on which the number of tire code contracts was recorded). The tires are then transported from warehouse to the box for the assembly. When the tires are stored, a contract is signed to ensure that after a contracted deadline of 6 months tires are kept for another 60 days, which is paid annually by $ 0.10 per tire daily. The price of tire storage depends on the size and is calculated per piece.
There is a possibility of joining the Loyalty Club and getting discounts for all family cars. The discount is valid only for services, not for products.
With companies that want the services of this tire service (rent-a-car, utility vehicles, etc...), a contract will be concluded to provide a more affordable price for tire assembly and storage.
Having a few issues with my database design. I have designed my system like the following image
As you can see it is a pretty basic system to a point. A user can create a supplier by adding supplier details. A user can then add a product and link it to a supplier. Thats the pretty straight forward bit (I hope!). Now I will attach my database design which should hopefully cover what I have mentioned.
So a supplier can have one contact (person within the suppliers company the user of my system will contact) and a supplier can have one to many products.
He is the part I can't figure out. Twice a week, the user of my system will receive stock from all their suppliers. When they receive this stock, they should go into the update stock screen within the application and input the amount of stock they have received for a certain product. I have added a products_stock table which should hopefully put me on my way to cover this aspect (I think it is missing a lot though).
The last screen however is a display of predicted stock. Lets say for instance on the day my products are delivered, I receive 10 units for Product One. I will then manually count the number of units I have left from the last order for Product One (say 2) and update the stock count for Product One to 12.
This means, that really, I only needed 8 units between the two deliveries for product one. The predicted stock screen is supposed to show the predicted stock levels I should place an order for, for a particular product, over a specified time period. So if 8 units was the average stock sold for product one per week, if I wanted to see how many units I should order for product one for a month, it should display about 32 units.
This is not supposed to be a complex system, it should have this manual aspect to it. I have designed the database up until a point, I was hoping I could get some suggestions regarding the products_stock table and how I can handle stock predictions for a specific period of time (if I maybe need additional tables).
Any advice appreciated.
Thanks
Inventory is more like a view and not a table. Inventory is really a series of movements of goods between locations, as well as periodic counts / adjustments.
Inventory is complex. You should play with some inventory software and read some data modeling books.
Use the concepts of Locations (real and virtual) and Movements (a movement should be its own entity).
Item smashes? Move it from its inventory location to the "damaged" location
Item went missing? Move it from inventory to the "ether" location
Found a random Item? Move it from "ether" to inventory
Sold an Item? Move it from inventory to "sold"
Bought an Item? Move it from purchased to inventory
Some other things to keep in mind:
You could sell something, and it's returned, and you put it back in
inventory
You could buy something, but it ain't right, so you send it
back to the seller
You could sell something that you don't own (on
consignment, or not in inventory yet)
You might have something in
inventory that is not currently for sale.
I won't get into the accounting aspects of inventory :)
One possible approach:
Have a separate "stock item" record for each unit received. When it is sold, record the date of sale in this record.
Then if you want to know how many items were sold in a given time range, just count the records with sold dates in that range, like select count(*) from stock_item where product_id=#product and sold_date between #from and #thru. If you need to keep track of items lost to spoilage, theft, whatever, then you might have a status flag of some kind that says whether it's in stock, sold, destroyed, whatever, and also the date of that status.
If the number of units that pass through is large and there's no other reason to keep individual stock records, you could just have "daily sales" records instead, with a date and number sold that day. Same idea.
I'm trying to make the database system point of sale, however I am confused between the entity and product inventory entity. What are the differences between product and inventory?
I know that the inventory should control the amount of product available .... but i have all that in products.
product code
name
description
cost
unit price
Subcategory code
brand code
amount available
Minimum quantity for rehearing
state
tax code
weight
amount wholesales
wholesales price
perishable
due date
creation date
upgrade date
what i should have in inventory? I have researched and according to what I read I need to have the product, the description, the quantity, purchase price, sale price, profit or gain and date of the transactions. But almost everything is in the Products table, what should I do?
A Product is an abstract Good or Service. A Good is the specification of an Asset.
Example "2014 Mazda 3" is a good. A "2014 Mazda 3 with VIN 12345" is an Asset.
A Catalog is the list of products that you want to sell. They don't need to exist yet, or you could be selling them for someone else.
Items Held For Sale are assets that you keep around to sell. These could be consigned (owned by someone else).
Inventory is an accounting concept. It is the dollar value of the items held for sale that you own, plus inbound and outbound goods that you're responsible for, plus any costs associated with holding that inventory.
You can track the value of inventory in a variety of ways such as FIFO and LIFO
I think you can store the inventory in the products table. There will certainly be transaction tables for purchases for the products and sales and even adjusting records (when items get count and the number differs from what's stored in the database), but you can easily work with the stock stored in the production table itself, thus not having to scan the whole database and sum up all purchases and sales and corrections every time (and never being able to delete old transaction data from the database, as that would invalidate the calculations).
However there are reasons to have stock stored in an inventory table instead. For instance if you want to store different statusses, e.g. you have 100 pieces in store plus twenty just arrived and still unchecked. Or you have a store with goods plus a warehouse housing additional stock. Or you have charges (different model numbers for example for a slightly altered product) which you offer as the same product, but still want to know how many old and how many new ones are in stock. And so on.
So make your mind up, if you want to store additional data with product stock, which would result in an 1:n relation instead of 1:1 which you have now.
There is the Foodmart database that was shipped with MS SQL Server 2000 for tutorial purposes. It has a table "sales_fact_1997" that has columns "store_sales" and "store_cost". What is the difference in their actual meaning?
Both store currency info - the amount of money that was involved in a transaction (along with pruduct ID, customer ID, store ID etc). It seems to me, that "store cost" means the prime cost of a product (money that the company spent to buy this product) and "store sales" means the product price (money that a consumer spent to buy this product from the company). The only thing that looks odd is that in average "store sales" ~ 2.5 * "store cost". 250% profitability seems TOO MUCH.
Most wholesale and retail accounting set-ups will have the two categories sales and cost of goods sold. If you thing a 150% (cost * 2.5 = sales is not 250% profit, it's only 150%) markup is unusual, you haven't done a lot of retail work.
What you have to understand is that cost of goods sold doesn't often include all the fixed costs like electricity, rents, wages and so on. They all have to be recovered as well.
Just out of interest, you might want to think about the marginal cost of Microsoft shipping a copy of Visual Studio once the initial costs have been recovered. It's nowhere near the hundreds of dollars that they charge for it and this goes some way to explaining why Bill G has so much money :-)