Using one MID to collect data across multiple sites, brings some issues with it, but is not impossible to solve.
The main issue is the expected difference in the traffic volumes between each site. Imagine one site having 10.000 (assume Denmark) product views per day, while the other having 100.000 (assume Germany). Since you are putting all these events in the same "bucket", there will be an overrepresentation of events collected on the "big" site. You need to take into consideration, that you might be getting products recommended, which are not available in that particular market.
When you build a recommendation scenario for Denmark, 90% of the products returned by the recommendation might not even be available there. So if you expect to receive a json with cross-site recommendations, you might not be able to filter out irrelevant items, and still have an acceptable number of products to present.
My key recommendation will be to create, in the same single catalogue, site specific product items. Assuming product id: 1234, you should end up with product ids: 1234_DE and 1234_DK for Germany and Denmark respectively. Each of the productYour catalogue will then have a tag field: Market, which can hold values DK and DE, and you will be able to create specific recommendations, where the use of rules will exclude recommendations from other markets, i.e.:
This will however require duplicating your recommendation logic for each site you want to support.
Yet another suggestion is to use Contact Attributes to exclude items. It still requires you to have duplicate items in your catalogue (one for each market/site), but here you can at least have just one set of recommendations, since the filter is based dynamically on Contact Attributes.
Setting Contact Attributes happens in the setUserInfo call, where you would normally set the identity of the visitor:
<script>
_etmc.push(["setOrgId", "12345678"]);
_etmc.push(["setUserInfo", {
"details": {
"Market": "DK"
}
}]);
_etmc.push(["trackPageView"]);
</script>
This will happen when this individual visits the site in question, mapping this relationship in the profile within Einstein Recommendation. Do keep in mind, you can only hold one value at a time, making this case less useful when a visitor can be expected to be browsing multiple of your sites. Then only the latest value set is stored.
There are few recommendation scenarios (e.g. most viewed), which might not return the expected results, and you might get few to none recommendations for the small websites, as they are "drowning" in the product views of the big ones, and the number of items stored for each the scenario is not indefinite.
