I figure there must be some way to do this with all of Google's Cloud AI tools, but I don't know where to start.
I have a dataset with:
User ID
Product ID
Purchase Date
I want to analyze the data to determine for each user, if there is a pattern of regular purchases of a product over time. For example, Customer X buys Product Y every 4 days. Or, projections of the dates Customer X will buy Product Y again.
How would I go about that with Google's AI tools?
Related
I want to calculate total transaction fees paid by users by using a substrate-api-sidecar on any substrate-based chain.
I tried reading two docs on calculating fees but none could help me out in deducing what to look for while querying a block. Click here for document 1, here for document 2.
Would that differ from chain to chain implementation?
I checked Moonriver documents on using substrate-api-sidecar and it seems possible to calculate fees. But I could not find out how to do so against a Polkadot parachain(relay chain)?
For setting the base premise, Token Terminal states that in a blockchain, total revenue generated means total transaction fees paid by the users.
In an application that has many 'shops' every registered admin user has a 'shop' entity, each shop sells items where each item belongs to a certain 'category'. Having multiple clients (100's in some cases) each client has an account to follow up on their purchases and past orders. Each shop generates invoices for their clients, clients pays the invoice.
Admin User -- > Shop
Shop ---> clients
|-> items Categories
|-> items
|-> invoices
|-> payments received
An admin page shows a report showing invoices within the year (from Jan to Dec) this page is a client requirement. The shop is able to manually generate a new invoice when a purchase is made, and records a payment when it is paid. Note: This all happens in the actual shop, there is no online client purchases.
As a single shop generates few invoices per month (~100's), and multiple payments per month (~100's), showing this per year easily goes to thousands entities to show on a single page.
To optimize loading the page and generating the sales year report (total sales, revenue, payment...etc.), we thought we'd structure the data in a way where each item category per year is also an entity. This means that whenever a purchase is made for an item in this category, we need to add the item's purchase price to the itemCategory at that year in this month.
itemCategory Model:
itemCategory(ndb.Model):
shopID = ndb.KeyProperty()
year = ndb.IntegerProperty()
monthly_sales = ndb.FloatProperty(repeated=True) #12 months
This way we can load the entire sales table by reading just the list of itemCategory for this shop for this year, instead of reading all individual purchases through the year. This would save lots of Datastore reads and decrease page load time on the expense of an extra read, sum & write to this summary like entity.
Category Jan Feb Mar ... Dec
--------------------------------------
Men's shoes 1000 1300 850 ... 1400
Kids shoes 600 850 650 ... 900
The challenge at this point is that strong consistency is quite essential, for individual purchases and for the itemCategory entities. Because if the shop tries to add multiple purchases in a successive short timed way, with eventual consistency itemCategory might have not been updated with the last purchase sum yet. Resulting in wrong sales values. Also the same for individual purchase if there was a requirement to edit one right after it was added, a query for the entity without its ID might have no results. So it seems that Ancestor queries is essential here with maybe the shop as the parent entity. Yet, this will result in a contention issue later on (at least until Datastore is migrated to Firestore) with all those entities (thousands in this case!) having one single parent!
The same goes for invoices, generating a new invoice means knowing the latest invoice number so that they are always in sequence without gaps. Querying invoice with eventual consistency may result in duplicate invoice numbers.
What is the optimum way to structure the data at this point for strong consistency? Unfortunately the project has been there for a few years, and was started using Google Datastore rather than Cloud SQL (which seem to be more appropriate for this kind of projects). Hopefully all these issues goes away after the migration to Firestore having Strong consistency for all reads
Consider exporting the data and then importing it into a Cloud Firestore in Datastore Mode project. No more eventual consistemcy issues.
There are certain ways you can achieve strong consistency.
Query using key. Whenever you try to read an object via its key it is strongly consistent.
Another approach would be to use NDB Asynchronous Operations. See related documentation here.
A really naive approach would be to provide a delay which could help you but the delay should be provided in such a way that it is sufficient for the object to get updated.
And the final approach could be to export data into Cloud Firestore. There you can achieve strong consistency always.
Hope this answers your question!!!
I'm trying to help my wife setup her site to use an Amazon API for pulling sales related information (i.e. specific product sales, prices, etc.) The simplest way to explain: she's a middleman for Seller A and Seller B. Seller A sells Product X and Seller B sells Product Y.
I want to know which Amazon API can authenticate using the main account since both products are sold under that account, specify Product X and pulls sales related data and return the sales information. I will then present this information to Seller A. Then, I specify Product Y using the main account to authenticate and then display this return to Seller B.
Which API from Amazon will accomplish this goal?
There isn't one. It's been asked for for years.
On an Amazon site, there is usually a List Price and a Price. I am trying to figure out how to obtain Price programmatically.
For example: This product has List Price $35 and Price $26
Through the ItemLookUp API, the List Price can be obtained easily but is there a way to get the Price from Amazon API?
First I thought that 'price' is the price that amazon sells the item at, but for this previously mentioned product this Price is $26 while the amazon's own lowest price is $28.76
Then I thought Price is the lowest price that is eligible for Prime, but I can't find easy way of getting this information.
If you make sure to include the Offers response group, you can get the lowest new price, lowest used price, etc. And if you need to, you can filter it to only offers from Amazon. That should give you the functionality you're needing. You can also find out if a specific offer is eligible for super saver shipping through that response group - which should be the same ones that are prime eligible.
Here's some more info on response groups and the different ones available - a very useful resource to dig through if you're wondering where to get a specific piece of info from.
I realize it's been a month since you asked this question, but I hope this helps. Let me know if you need any more clarification.
I'm looking for advice on best practice for annual subscription management where the fees may change each year.
I have a Membership and MemshipYear models as well as the User models. Each membership category (membership.category) has an annual fee which may be different. Members will be able to download pdf invoices for membership fees at any time once logged in.
The pdf is generated at the time of request and the data is taken from the membership model. Therefore if the membership fee changes after one year the invoice would be caluclated with this figure and not the fee for that year.
One thought I had was to use price banding i.e A-F, and have a price band for each category for each year.
I reckon there's a better way.Anyone?
Logically, the membership itself should have a price, since that inherently belongs to the user. On creation, you would set this value from the category. Then, whenever you need to get the current price the user is paying, you pull it from their membership, instead of the variable price on the category.