I am implementing schema ratings and reviews on the same page. Users can add a star rating or add a review with a star rating. When this happens I combining the two and outputtng the ratingvalue.
I can get them both working using the google data testing tool with reviewCount or ratingCount. Though I am wondering which is better to use, the reviewCount or ratingCount, or it doesn't matter?
Cheers
Both are different.
reviewCount: The count of total number of reviews.
ratingCount: The count of total number of ratings.
Please refer here for further details
ratingCount: The total number of ratings for the item on your site. At least one of ratingCount or reviewCount is required.
reviewCount: Specifies the number of people who provided a review with or without an accompanying rating. At least one of ratingCount or reviewCount is required.
Source: https://developers.google.com/search/docs/data-types/reviews
Related
I have two collections
Customers
Products
I have a field called "orders" in each of my customer document and what this "orders" field does is that it stores a reference to the product Id which was ordered by a customer, now my question is since I'm referencing product Id and if I update the "title" of that product then it will also update in the customer's order history since I can't embed each order information since a customer may order thousands of products and it can hit 16mb mark in no time so what's the fix for this. Thanks.
Create an Orders Collection
Store ID of the user who made the order
Store ID of the product bought
I understand you are looking up the value of the product from the customer entity. You will always get the latest price if you are not storing the order/price historical transactions. Because your data model is designed this way to retrieve the latest price information.
My suggestion.
Orders place with product and price always need to be stored in history entity or like order lines and not allow any process to change it so that when you look up products that customers brought you can always get the historical price and price change of the product should not affect the previous order. Two options.
Store the order history in the current collection customers (or top say 50 order lines if you don't need all of history(write additional logic to handle this)
if "option1" is not feasible due to large no. of orders think of creating an order lines transaction table and refer order line for the product brought via DBref or lookup command.
Note: it would have helped if you have given no. of transactions in each collection currently and its expected rate of growth of documents in the collection QoQ.
You have orders and products. Orders are referencing products. Your problem is that the products get updated and now your orders reference the new product. The easiest way to combat this issue is to store full data in each order. Store all the key product-related information.
The advantage is that this kind of solution is extremely easy to visualize and implement. The disadvantage is that you have a lot of repetitive data since most of your products probably don't get updated.
If you store a product update history based on timestamps, then you could solve your problem. Products are identified now by 3 fields. The product ID, active start date and active end date. Or you could configure products in this way: product ID = product ID + "Version X" and store this version against each order.
If you use dates, then you will query for the product and find the product version that was active during the time period that the order occurred. If you use versions against the product, then you will simply query the database for the particular version of the product itself. I haven't used mongoDb so I'm not sure how you would achieve this in mongoDb exactly. Naively however, you can modify the product ID to include the version as well using # as a delimiter possibly.
The advantage of this solution is that you don't store too much of extra data. Considering that products won't be updated too often, I feel like this is the ideal solution to your problem
How can I get orders thru Shopify API where the id is greater than xxxxx?
Something like:
admin/api/2020-01/orders.json?id>=1900000000
or
admin/api/2020-01/orders.json?min_id=1900000000
I hope you understand what I mean.
If you read the documentation you see that orders have a created_at_min and created_at_max. Those values are what you use as your filter criteria for dates. If you need to work off of ID then you can try the since_id filter. In other words, give me all order since 123456. You get what I mean?
I'm designing a REST API where you can search for data in different countries, but since you can search for the same thing, at the same time, in different countries (max 4), am I unsure of the best/correct way to do it.
This would work to start with to get data (I'm using cars as an example):
/api/uk,us,nl/car/123
That request could return different ids for the different countries (uk=1,us=2,nl=3), so what do I do when data is requested for those 3 countries?
For a nice structure I could get the data one at the time:
/api/uk/car/1
/api/us/car/2
/api/nl/car/3
But that is not very efficient since it hits the backend 3 times.
I could do this:
/api/car/?uk=1&us=2&nl=3
But that doesn't work very well if I want to add to that path:
/api/uk/car/1/owner
Because that would then turn into:
/api/car/owner/?uk=1&us=2&nl=3
Which doesn't look good.
Anyone got suggestions on how to structure this in a good way?
I answered a similar question before, so I will stick to that idea:
You have a set of elements -cars- and you want to filter it in some way. My advice is add any filter as a field. If the field is not present, then choose one country based on the locale of the client:
mydomain.com/api/v1/car?countries=uk,us,nl
This field should dissapear when you look for a specific car or its owner
mydomain.com/api/v1/car/1/owner
because the country is not needed (unless the car ID 1 is reused for each country)
Update:
I really did not expect the id of the car can be shared by several cars, an ID should be unique (like a primary key in a database). Then, it makes sense to keep the country parameter with the owner's search:
mydomain.com/api/v1/car/1/owner?countries=uk,us
This should return a list of people who own a car with the id 1... but for me this makes little sense as a functionality, in this search I'll only allow one country:
mydomain.com/api/v1/car/1/owner?country=uk
I would like to use schema.org markup on my site. There are rating options/values to use but I need ranking. Only thing I can think to do is use rating of 10 stars = ranking of 1, rating of 9 stars = ranking of 2, etc. I was using search in google and was directed here to post question. If there is someone from google or familiar with schema.org values please comment. Best option would be to add ranking as a feature of schema.org. Thanks for the help.
There is no a ranking property in any of the schema items but rankings are just ordered lists, they specify the relationship of things between them in a list.
You can use https://schema.org/position to set each item position in an ordered list https://schema.org/ListItem simulating a ranking.
In the user based Collaborative Filtering, the picture shows the formula of how to predict the rating of an item. And the NSa is the nearest neighbor set of user a. j is the item to be predicted. rij means the rating of item j by the user i in the NSa. So, my question is,what if the user i has never voted the item j? How to handle the rij? Thanks!
The sum is really over all the users in NSa that have also rated j. That's the usual answer, to restrict it this way too. You could also use some dummy value here when it doesn't exist, like using the average rating of user i instead. I don't recommend this as it slows things down without adding information.