Hi there!
we are having problems with changing userIds for Google Actions (using dialogflow). Voice Match is activated but we are getting a new userId each starting session.
After some debugging I can see that the google devices are not sending a userId inside their first Launch Request anymore. The GoogleAssistantCore is searching for user.userStorage.userId which is not defined and therefore generates a new User (with new Id).
Hi Andre,
Does this happen for any user? Only specific devices?
Could you share the request JSON?
@jan yes it is each user. @ms169 and I tried it on different devices with different account and settings.
Usually my user object inside my request looks like this:
"locale": "de-DE",
"lastSeen": "2020-11-18T12:06:45Z",
"userStorage": "{\"userId\":\"38361882-5934-4628-96ae-1dea98990f49\"}",
"userVerificationStatus": "VERIFIED"
},
when starting the session it now the userStorage is missing:
"locale": "de-DE",
"lastSeen": "2020-11-18T12:06:59Z",
"userVerificationStatus": "VERIFIED"
},```
As far as I understand it the GoogleAssistantCode is saving the requests userId inside the jovo.$user.$storage.userId field when starting a new request:
Afterwards the JovoUser is loading the user by calling the `getId` Method of the GoogleActionUser:
So a request (like launch momently) without an userStorage Object will always result in generating a new user via `uuidv4()`. Am i missing something?Do you think there is a different way how the user object should handle this? If there is no user storage, there is not much we can do as far as I understand it
I think the questions is: What Change did dialogflow make? Has there always been userStorage Objects in launch requests? Is it a problem with devices not sending their user ID for already known actions? How does the google SDK handle this.
Maybe you can answer the first question @jan? Can you reproduce this issue?
I faced the same problem with GSUITE accounts. Here’s an overview of some use cases I tested a few weeks ago.
@AlexSwe thanks! So the result “randomUserId” also was due to a missing userStorage inside the request? Did you trigger the row random user ID by deactivating voice match?
@dominik-meissner @ms169
@AlexSwe we tested our actions with private google accounts and received similar problems (tested with 5 accounts on different actions). Nevertheless the problem seems to be linked to certain accounts. We have one account which works correctly - our GSuite Account! Actions triggered from this account (no matter if alpha testing, simulator testing or on-device testing) will always send an userId at session start if this action was triggered by this account before.
One interesting point is that within the userStorage is a property called “LastSeen”, which can be user to verify if this user really is a new user or just a returning user not sending his/her userId.
@AlexSwe @jan for me enabling the setting for web and app activity inside the google assistant app fixed this behavior. Could you try verify if this is the case for you too? If I enable the first checkbox my userId is there again
Main User: ID is available in user storage
Random User: Nothing is stored in user storage, new ID is generated
