@HT87 opened this issue on March 7th 2016

I am currently trying to use image source tracking code within an email. This will mean that we can track anyone who visits our site and has opened our emails (perhaps in another session).

The tracking is working, but we noticed that different users within the same network (same ip) get given the same visitor id. I believe this is similar to the intranet tracking issues (http://piwik.org/faq/how-to/faq_175/); we have already forced piwik not to use the ip address - but this does not seem to work in this case.

I think that this issue may be arising as it is normally the web browser that sets the cookie, and in this case outlook will be setting it - and i'm not sure outlook has that functionality.

Another issue that does not help matters is that we are currently using 1st Party cookies, I believe we will need to switch the 3rd party cookies to track the user from the email to the site, using the cookie. However the 1st party cookies enables us to test how the cookie is set in the first instance.

Before I enable the 3rd party cookies, I am keen to understand how the cookies would be set within email tracking, and how to ensure two users are not seen as one when using the same IP - which would most likely be achieved through controlling how the cookie is set.

Once this is done, I am assuming I can simply turn on third party cookies and tracking should work, without the duplicates?

Many thanks for any help

@tsteur commented on March 7th 2016

I've never tried it but it can be tricky indeed.

Maybe have a look at the tracking API: http://developer.piwik.org/api-reference/tracking-api

Eg if you have userIds / userLogins etc you could make use of the UserID feature and append eg &uid=myLogin to the image tracking code (if this is possible for you re privacy etc). You could also anonymize the login / userId.

Interesting could be also cid see documentation:

cid — defines the visitor ID for this request. You must set this value to exactly a 16 character hexadecimal string (containing only characters 01234567890abcdefABCDEF). We recommended to set the User ID via uid rather than use this cid.

Basically you would generate a random visitor id for each email recipient and add it to the image tracking code.

There might be a problem that user gets a different visitorId after actually clicking on a link and opening a page on your website. There are ways around this (eg passing visitorId cid) in all URLs to your page and setting the same visitorId there via piwik.js. Hope it's kind of clear :)

There might be other ideas but never tried any of them :)

@tsteur commented on March 7th 2016

@mattab maybe this is something for FAQ and quite useful, also for SEO?

@HT87 commented on March 7th 2016

Hi Thomas

Thanks for your reply

The issue is that this is a consumer site, I.e some visitors are generated from clicking emails others are direct traffic, out hope is to tie previous and future direct visits to an email address, by using a cookie.

So if someone has been to the site, and has had a cookie set, then gets an email, I would like the cookie to be the same.

Likewise when opening an email and then visiting the site at a later date, the cookie should be the same too.

If we force the cookie to be a certain number at the point of email, how can I track past or future email activity to it?

Regards

Howard Thompson

Sent from my iPhone

On 7 Mar 2016, at 20:15, Thomas Steur notifications@github.com wrote:

I've never tried it but it can be tricky indeed.

Maybe have a look at the tracking API: http://developer.piwik.org/api-reference/tracking-api

Eg if you have userIds / userLogins etc you could make use of the UserID feature and append eg &uid=myLogin to the image tracking code (if this is possible for you re privacy etc). You could also anonymize the login / userId.

Interesting could be also cid see documentation:

cid — defines the visitor ID for this request. You must set this value to exactly a 16 character hexadecimal string (containing only characters 01234567890abcdefABCDEF). We recommended to set the User ID via uid rather than use this cid.

Basically you would generate a random visitor id for each email recipient and add it to the image tracking code.

There might be a problem that user gets a different visitorId after actually clicking on a link and opening a page on your website. There are ways around this (eg passing visitorId cid) in all URLs to your page and setting the same visitorId there via piwik.js. Hope it's kind of clear :)

There might be other ideas but never tried any of them :)

— Reply to this email directly or view it on GitHub.

@tsteur commented on March 7th 2016

If we force the cookie to be a certain number at the point of email, how can I track past or future email activity to it?

I see, this is not easily possible. From the sounds you would need to save the idVisitor which you can get eg from piwik.js in your application along with an email address in case you can map it somehow. Eg at the time you get an email address, you would query piwik.js to getVisitorId eg _paq.push(['getVisitorId']) and save both information in DB. Then when sending emails you would need to import both fields into your email tool and set the visitorId again via the image source. This would only work for new emails that you get and is rather quite complicated.

The only thing would be to always use email address, or a hash of email, as uid in emails and in your website. A user would possibly need to be logged in for this, otherwise you likely won't have the email address. Once a user logs in and you set a userId, all previous actions within that single visit will be linked to that user. However, previous visits that were done in a "logged out state" by that visitor would be basically a different "visitor". It's complicated :)

Maybe @mattab has an idea

@mattab commented on March 15th 2016

@tsteur you explained well how it could work. I believe we can mark this as duplicate of https://github.com/piwik/piwik/issues/6781

@HT87 feel free to continue discussion in #6781

This issue was closed on March 15th 2016
Powered by GitHub Issue Mirror