Attachment: Page Title with Segment selected (and different usage time)
page_titles_with_segment.png

Attachment: Page Title without Segment selected
page_titles_without_segment.png

Attachment: Page Title with Segment selected (and different usage time)
page_titles_with_segment.2.png

Attachment: Correction: Page Title with Segment selected (and different usage time)
page_titles_without_segment.2.png

I believe we are seeing a different manifestation of the same problem.

We want to take advantage of the segmentation feature to send each segments' content manager a monthly report email (html, not pdf) via the built-in reporting tab that has only "Actions: Page titles" chosen. We noticed that the avg. time on page that we saw drilling down from the default "All visits" segment did not match the avg. time spent in our reports for any specified segment, even though the other stats matched. I am able to see the avg. time mismatch between "All visits" and any chosen segment in the Piwik interface as well, so it doesn't look like it's a problem with generating the report.

For an example, I have attached two screen shots that I think should be reporting the same information. The file piwik-dsg-segment shows our segment DSG (defined by Page URL here) had an avg. time on page of 20s. In the file piwik-all-visits-dsg, the DSG Home Page statistics match DSG segment's - with the exception that the avg. time on page is reported as 2min 29s.

I have re-read the documentation on how to set up segments and tried using various definitions for the segment, but I cannot get the avg. time for a segment to match the avg time that is reported by drilling down from "All visits" under Actions: Page titles. [The stats for my various segment definitions did match each other though!] If I'm missing something, please let me know.

Bug #4719 was apparently opened per Stefan's question above and is now a low priority. I have two questions:

1. Is there any chance this can be fixed in the next month or two?
2. Is there any work around?

Thank you for any assistance you can give me.

Cheers,
Amy

I looked into this but unfortunately I'm not sure the correct way we could solve this bug.

The SQL Query with segment on page url looks like:

            SELECT
                log_link_visit_action.idaction_url_ref as idaction, log_action.type, log_action.name, count(*) as `12`,
                sum(log_link_visit_action.time_spent_ref_action) as `13`
            FROM
                piwik_log_link_visit_action AS log_link_visit_action
                LEFT JOIN piwik_log_action AS log_action ON log_link_visit_action.%s = log_action.idaction
            WHERE
                ( log_link_visit_action.server_time >= ?
                AND log_link_visit_action.server_time <= ?
                AND log_link_visit_action.idsite = ?
                AND log_link_visit_action.time_spent_ref_action > 0
                AND log_link_visit_action.%s > 0 AND log_link_visit_action.idaction_event_category IS NULL )
                AND
                ( ( log_link_visit_action.idaction_url IN (SELECT idaction FROM piwik_log_action WHERE ( name LIKE CONCAT('%', ?, '%')  AND type = 1 )) ) )
            GROUP BY
                log_link_visit_action.%s, idaction
            ORDER BY
                `12` DESC, log_action.name ASC"

The problem is that the segment on Page URL is applied to this query (( ( log_link_visit_action.idaction_url IN (SELECT idaction FROM piwik_log_action WHERE ( name LIKE CONCAT('%', ?, '%') AND type = 1 )) ) )) which restricts the rows that we query. As a result, I believe that only Pages which were redirected to this page are counted in the "Average time on page".

Fix? when we process the average time on page in the Actions Archiver, maybe we could skip and do not apply the Page URL segment - in function archiveDayActionsTime

Thanks for contributing to this issue. As it has been a few months since the last activity and we believe this is likely not an issue anymore, we will now close this. If that's not the case, please do feel free to either reopen this issue or open a new one. We will gladly take a look again!