User ID not persistent

[dobesv]

It seems like on initial page load we set the User ID and it is sent to Piwik. However, after that the future events sent to piwik have some randomly generated hex uid instead of the one we set. This results in the user's session not being tracked properly.

My workaround is to use custom variables for the User ID instead.

[inolasco]

Just to be thorough and rule out the obvious, are you calling $analytics.setUsername(the_user_id);? Is there any place where it might be getting called again and set a null or undefined value?

I think this could mean we need a $window._paq.push(['trackPageView']); right after calling piwik's setUserId. Would you be able to add it and try it? I'm not able to test it at the moment, but I can try it later if not.

[dobesv]

I was adding the user ID myself in the tracking code js. The user ID is
sent for the first request but reverts back to a uuid for the following
requests.

I have since realized that Piwik's user ID feature is not what I want,
though, since it treats the user as a different visitor when they log in
and out, whereas I want the user ID to cover all the user's actions before
logging in so I can track them through a funnel.

It's possible this is an issue with Piwik. Maybe we would have to set the
user ID before every event we send?

I had previously tried calling analytics.setUsername as you suggested but I
couldn't get it to work, I think I was calling it after the page view was
already sent so it didn't have any effect. I'm not sure how to hook that
in to run at the right time.

I have also noticed that two events are being sent to Piwik on the first
page load but I suspect that is probably my fault somehow, I just haven't
figured it out yet.

On Thu, Sep 22, 2016, 7:54 AM Ivan Nolasco notifications@github.com wrote:

Just to be thorough and rule out the obvious, are you calling
$analytics.setUsername(the_user_id);? Is there any place where it might
be getting called again and set a null or undefined value?

I think this could mean we need a $window._paq.push(['trackPageView']);
right after calling piwik's setUserId. Would you be able to add it and
try it? I'm not able to test it at the moment, but I can try it later if
not.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#7 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUAmc-VExvkfbEcM3ycbEMqVMEdmLZ1ks5qspaggaJpZM4KDG6F
.

[inolasco]

For tracking the user before login in, the easiest approach I can think of is using cookies to store a UUID for the user, and use that in the setUsername call. The problem is that if the cookie is cleared, the user might be tracked as a new visitor when login in again, which may or may not be an issue depending on your requirements. You might want to store the userID as a custom variable variable in that case, so that you have both the userID and the cookie.

[dobesv]

Yeah I switched to a custom variable, I'll see if that works the way I
want. It's too bad the user ID feature in Piwik doesn't work that way,
because now I can not track users across devices.

On Thu, Sep 22, 2016, 8:19 AM Ivan Nolasco notifications@github.com wrote:

For tracking the user before login in, the easiest approach I can think of
is using cookies to store a UUID for the user, and use that in the
setUsername call. The problem is that if the cookie is cleared, the user
might be tracked as a new visitor when login in again, which may or may not
be an issue depending on your requirements. You might want to store the
userID as a custom variable variable in that case, so that you have both
the userID and the cookie.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#7 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUAmaerxiS-zMBlTAilVkFY_2635Ajhks5qspyMgaJpZM4KDG6F
.