User visits do not seem to be tracked properly.

[sdunnin]

We are registering visits from an Android application. When viewing from the dashboard visits and unique visitors are accurately reflected, however, when calling API method VisitsSummary.getUsers and providing parameter &segment=visitorType==returning the value returned is always zero. The user visits all register as new users even though the users have multiple visits across several days.

Website visits reported via the javascript client do report new vs. returning visitors. Both Javascript and Java clients are sending the userid via the uid paramater.

[d4rken]

Are you storing a user-id? As i currently understand it, a visitor-id is generated and used to track a visit for the duration of the current app instance, but each time the app is restarted you will get a different visitor-id. So you have to persist a user-id which is reused each time the app is open.

[sdunnin]

Yes, we pass a consistent userid in the api call from the Android application.

[d4rken]

I don't think this issue will see any progress without further testing from your side. I suggest to debug your app to make sure that a userID is being transmitted.

If you can not find anything through debugging try to create a simple as possible app that reproduces this.

Possibly you spot an issue and we can enhance the unit tests to catch this in the future.

I'm currently still integrating the sdk into my app and if i find anything I'll report back.

[d4rken]

In my live test the Piwik webpage seems to report a non-zero value for returning visists, although this is with the current dev-branch i found no issues during my changes that would suggest an issue with this.

when calling API method VisitsSummary.getUsers and providing parameter &segment=visitorType==returning the value returned is always zero.

As the API method for this is not part of the Android-SDK but the main Piwik SDK wouldn't it make sense to close this ticket and create one here: https://github.com/piwik/piwik/issues

[d4rken]

I think we need to reopen this @dotsbb

I can randomly pick entries from the live visitor log and see that they have multiple visists across multiple days. "Visits by days since last visit" aswell as "Visits by Visit Number" should have significantly higher values in other rows.

As @sdunnin issue was reported before the Tracker rewrite, this doesn't seem to be a regression from my Tracker rewrite.

• Creating a segment for "Visitor Type IS NOT" only offers autocomplete to "NEW" and shows a too low number
• Creating a segment for "Number of visits AT LEAST 2" shows 0 zero results.
• If i create a segment for visitorType="returning" i get about 200 entries but on closer inspection all entries just have 1 visit. How is that possible?

So under the visitor log the data appears correctly, but no where else.

[d4rken]

This must be related to one of these paramters:

_id (recommended) — The unique visitor ID, must be a 16 characters hexadecimal string. Every unique visitor must be assigned a different ID and this ID must not change after it is assigned. If this value is not set Piwik will still track visits, but the unique visitors metric might be less accurate.

We set this to a unique random value on a per visit basis. Meaning if you kill the app and open it again you get a new unique value for this field.

uid — defines the User ID for this request. User ID is any non empty unique string identifying the user (such as an email address or a username). To access this value, users must be logged-in in your system so you can fetch this user ID from your system, and pass it to Piwik. The User ID appears in the visitor log, the Visitor profile, and you can Segment reports for one or several User ID (userId segment). When specified, the User ID will be "enforced". This means that if there is no recent visit with this User ID, a new one will be created. If a visit is found in the last 30 minutes with your specified User ID, then the new action will be recorded to this existing visit.

We set this to a unique value that doesn't change unless the app is reinstalled.

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.

We don't use this.

TL;DR: A unique visitorID for each visit (treated as "session id"?) and a unique userID for each install. @mattab ?

[d4rken]

According to https://github.com/piwik/piwik-sdk-ios/issues/46 we are correctly using the ids. It seems the visitor ID doesn't even matter when the userid is set.

Everything seems to work correctly as entries are grouped toegether correctly in the live visitor log, but then again when we create a filter segment for "Number of Visits" > 1, it shows no results. I would have created a test segment on the piwik demo instance, but it requires admin access.

[d4rken]

Well holy shit, i think the solution is very simple. Ofc the values are missing, these things are tracked server-side. From http://developer.piwik.org/api-reference/tracking-api Number of visists:

_idvc — The current count of visits for this visitor. To set this value correctly, it would be required to store the value for each visitor in your application (using sessions or persisting in a database). Then you would manually increment the counts by one on each new visit or "session", depending on how you choose to define a visit. This value is used to populate the report Visitors > Engagement > Visits by visit number.

Last visists:

_viewts — The UNIX timestamp of this visitor's previous visit. This parameter is used to populate the report Visitors > Engagement > Visits by days since last visit.

So i would assume that the "returning visitor" count is depending on those values being set. I'll test that now.

@mattab Why is the server not tracking the visit count / visit time? He already has access to those values. Is it a performance issue? Because having the server do this would also fool proof it against the client transmitting bogus values.

[d4rken]

See #50. Not transmitting "_idvc", "_viewts" and "_idts" was the problem. Filtering for visitor type "returning" does now also work. I'll be deploying this soon in a larger test again, but tests on my demo server were already pretty promising.

@mattab I'd still love to know why the server doesn't do this for us, but I'm now betting on performance concerns. @sdunnin Try the dev branch after the PRs have been merged and let me know whether it's working. @dotsbb After merging the PR we can close this again ;).

[d4rken]

Days since last visit was not yet working correctly but should now be after #53 is merged.

[d4rken]

@dotsbb Let's close this one again. Values do look correct now. Except for a few freakvalues which are unavoidable if you trust user values.