Subscribers without subscriberId
I am currently storing device tokens in my database. When users authenticate, I link their user_id with the corresponding device token to identify which device belongs to which user. I want to do the same in Novu too. I would like to create a subscriber in Novu and later update it with the user_id as the subscriberId. In this way I would be able to send general push notifications to users without user_id and later send personolised ones when they will have user_id. However, it seems that the subscriberId cannot be updated. How should I handle this situation? Are there any best practices for such a case?
I thought about putting device token as a subscriberId in the beginning (when I don't have the user_id yet) and later, when I will have user_id, create a completely new subscriber with user_id as a subscriberId and delete the initial subsriber with device token as a subscriberId, but it's kind of weird.
Thanks in advance.
5 Replies
Hey narek
Do you have any other unique identity about this user like email or phone number?
Do you have any other unique identity about this user like email or phone number?
Unfortunately no. In the begining, when I am getting device token, I don't have anything about the owner of that device, but I still want to send him general push notifications and be able to identify him at some point when he will authenticated.
@Narek, you just advanced to level 1!
One workaround that I can suggest is this
1. create subscriber with unauthenticated userId as subscriberId.
2. store device tokens for this subscriber
3. when this user becomes authenticated, create a new subscriber with a new authenticated userId as subscriberId and store the same device tokens for this subscriber
4. subscriber field has
Ideal solution would be to have a merge subscriber option. I am sharing the feedback with team
data field, store old subscriberId in this data field of new subscribers for future reference
Will that workaround work for you?Ideal solution would be to have a merge subscriber option. I am sharing the feedback with team
Thank you very much. Your idea solves the current problem. Logic of merge will be better, but right now we have what we have.