User Id

[Magnus Indregard]

Hi,

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)

Br,

Magnus

[Yuening Hu]

Hi, Magnus,

Thanks for your feedback.

Exactly as what you said, user_id is playing a role in the recommendation results. What you saw seems to be unexpected. 

To confirm, a few initial questions to check with you:

- is this a new problem after GA migration or do you also have the same problem with beta API? 

- do you ingest user_id in event ingestion? and user_id in event ingestion is the same as in predict request?

- Are you doing real time event ingestion or batch? If batch, at what frequency?

To further understand what exactly happening here, would you mind providing your project_number, some example requests with user_id and visitor_id, so that we can take a deeper look there? 

Best,

Yuening

--
You received this message because you are subscribed to the Google Groups "cloud-recommendations-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloud-recommendatio...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cloud-recommendations-users/b4ffffd2-f1e4-489e-9a9b-f905550ff8d7n%40googlegroups.com.

[Magnus Indregard]

Hi Yuening,

Thanks for getting back to me, and for confirming that this is not the expected behavior. 

To your questions:

- We get the same results from the v1beta and the v2 APIs, so no change there.

- We do ingest user_id with around 15% of user events. We use the same user_id in the predict request as in event ingestion. 
- We are doing real-time ingestion, using the Cloud Retail tag template in Google Tag Manager.

At the time of sending the predict request, we will in a lot of cases only know the user_id of a user. For these users, we use a fake visitor_id, after visitor_id became mandatory in predict requests in v2. So these requests will have a new visitor_id, which has not been included in any events. However, the user_id will not be new and will have been ingested in user events earlier. When sending the predict request, we already know that the user has been identified on the site before and that they will have generated events with their user_id. 

I will get back to you with the project_number and some sample requests. 

Thanks, 

Magnus