What is the role of user_id in recommendations? I expected it to work in the same way as it does in GA - that is to tie together events from different visitor_ids, and treat these as coming from the same user.
In context of recommendations, this should mean that we would get meaningful recommendations for a user, even when their visitor_id has been reset, based on having a user_id in the request, which has also been submitted as part of events. This would make a lot of sense, as cookies are more and more short lived, meaning that the visitor_id is renewed more often.
We have a project where we have tested this in practice. This is a web shop where users are identified quite often, and a significant amount of the events sent to Cloud Retail API include both user_id and visitor_id. However, when we request recommendations for users with a valid user_id, but with a fresh visitor_id (that is, a visitor_id that has not been included in events), we get the generic recommendation back 99.9% of the time. (The generic recommendation = the recommendation you get when you submit an invalid visitor_id / user_id).
This is both disappointing and confusing. What is the point of sending user_id with events if it can't be used to generate recommendations?
When we started building this, we used the v1beta API. In the v2beta API, we were allowed to send recommendation requests with either visitor_id or user_id (and to omit the other). We have since then migrated to the v2 API, and now visitor_id is mandatory, which I guess is an indication that recommendations are mainly based on visitor_id. Still, I'd like to think that user_id should play a part as well.
(Using the 'Recommended for you - CVR' model BTW)