|Dependency Graph||View Issue Relation Graph Vertical|
View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019293||phpList 3 application||Statistics||public||21-06-18 15:35||18-02-19 10:33|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||3.5.0||Fixed in Version|
|Summary||0019293: Add 'unsubscribes' to Statistics Overview page and subtract it from click statistics|
|Description||Currently the 'Unique clicks' column of the statistics overview page includes clicks of the 'unsubscribe' and 'preferences' links. This means that a campaign which was disliked by its recipients, and for which the only clicks were unsubscribe clicks, can appear more successful than it really is when only the click statistic is viewed.|
To remedy this, deduct the clicks on these links from the numbers within the 'Unique click's column on this page, and also from the 'campaign statistics' and the 'Click details for a campaign' page (e.g. from the 'click rate'). Additionally, list the number of successful unsubscribes (e.g. the number of subscribers who not only clicked the 'unsubscribe' link but who completed the unsubscription process) on the 'Statistics overview' and 'campaign click statistics' page.
|Tags||No tags attached.|
yes, very good. It may be quite tricky to compile these stats though. I think we may need to have some kind of tracking var in the session, that follows the trail.
eg. unsubscribe status -> started -> updated -> finished
and keep the stats of each of these.
Remember that unsubscribes work in a variety of ways:
JUMPOFF true -> load the link immediately unsubscribes
JUMPOFF false -> request reason why (multi stage) and only unsubscribe when answered.
also, the "jo" variable in the URL overwrites "JUMPOFF" regardless of the setting in the system. The "jo" var is added to Header fields, so you can track all kinds of different stats on the unsubscribes.
Also unsubscribers through too many bounces should be added to the mix. But those are not specific to a campaign. So, you can't give the stats on the campaign performance, only on the total performance.
These stats are not easy to compile. In general, I've always tried to stay away from "a campaign causes unsubscribes" and treated it as "the entire operation causes unsubscribes". But I agree this may not always be so obvious.
I think this would be a great improvement as the statistics will be more accurate.
Also, I think it's easy the system can differ between unsubscribed subscribers and subscribers blacklisted due to the number of bounces - isn't the blacklisted subscriber removal an example for that ? ("Delete subscribers who are blacklisted because they unsubscribed”", "Delete all blacklisted subscribers").
> Also, I think it's easy the system can differ between unsubscribed subscribers and subscribers blacklisted due to the number of bounces - isn't the blacklisted subscriber removal an example for that ? ("Delete subscribers who are blacklisted because they unsubscribed”", "Delete all blacklisted subscribers").
Yes, for the most part. Xheni can investigate further during implementation.