View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019416||phpList 3 application||phpList||public||15-09-18 20:13||18-09-18 07:54|
|Summary||0019416: Associate transactional messages with lists, not subscribe pages|
|Description||Currently, the architecture of phpList associates transactional messages with subscribe pages. There are multiple problems with this. Conceptually, transactions occur between a subscriber and a list, not between a subscriber and a page.|
This is best explained by considering the case of unsubscribe transactions, and it can be summarized by pointing out that subscribers sign off from a list, not from one of potentially multiple methods of getting on that list.
The practical test described in "Steps To Reproduce" illustrates a problem that arises from this architectural flaw:
This is not just an issue of a poor choice of which message to send in that specific case. There is potentially a many-to-many relationship between subscribe pages and lists, and subscribers can be imported without the use of a subscribe page. The only way to ensure that the desired unsubscription response message is sent when a subscriber unsubscribes from a list is to associate that transactional message (and others, naturally) with the list the person is signing off from.
The following scenario demonstrates the many-to-many complexity that results in ambiguity of message content when transactional messages are not tied directly to lists.
Consider Farmer Pat who has the lists Apricots, Bananas, and Carrots (A, B, C) for people who like locally-grown fruit, people who like imported fruit, and people who like vegetables, respectively. On Pat’s site there is a phpList subscribe page (S - site) that offers A, B, and C. Pat also hosts a forum for fruit importers and has a subscribe page there (F - forum) that only collects subscribers for B. When Pat has a stand at the local market, there’s a paper sign-up sheet (M - market), and Pat manually adds those subscribers to all three lists.
This illustrates a many-to-many scenario. Subscription methods M and S offer A, B, and C. And, lists A, B, and C can be subscribed to via (M, S), (F, M, S), and (M, S), respectively.
Now assume that Pat self-publishes a book offering guidance on importing rare fruit, and wants to add a plug for that book in the unsubscribe message for list B. Pat wants to make sure that anyone who signs off from B will see that message. Where should Pat make those changes, since there are three ways somebody could be on that list? And what happens when Kim, who provided an email address on the paper sheet at the market, signs off from list B, i.e., what unsubscribe message is sent to Kim?
|Steps To Reproduce||1. Create a CSV with a test subscriber|
2. Import the CSV and select a test list that is not shown on any subscribe page
3. Send a campaign to the test list
4. Use the unsubscribe link in the email received by the test subscriber
5. Compare the content of the unsubscription transaction message received by the test subscriber against the “default” message defined in Settings and the message defined in an actual subscribe page.
What I should have seen: A message other than the one defined with the subscribe page (because that subscribe page was not used), so presumably either a phpList default message or the one defined in Settings.
What I saw: The message defined with the subscribe page.
|Tags||No tags attached.|
Thanks for the contribution. Yes, I think it is quite debatable how it works. In a way, maybe transactional messages need to be system only and not subscribe page or list at all. They could then be simple ones, like "thanks" and "you have signed up for our information". I'd welcome further discussion on how to make this work better.
The trouble comes partly from mixing imported and actually signed up subscribers. If all subscribers were to sign up with subscribe pages only, all would be much clearer. Nevertheless even then it's not all perfect.
Another issue is the fact that if you have subscribers signed up to page X (with list A and B) and then page Y (with list C and D) and they unsubscribe, they may not want to unsubscribe from A and B but do from C and D. There's a whole lot of functionality that could be added to allow for this to happen more smoothly than it does now. Currently, all you can do is send them to the preferences page, but really the unsubscribe page should list the possible options and allow "selective unsubscription".
But on the whole, I think you are trying to be fairly specific about your targeting of plugs. If I look around the internet, it's only the really big players who are able to do that. Farmer Pat should probably just plug anything to anyone (s)he can get the contact details for. I don't think that vegetable fans will get terribly upset being reminded of buying a book on importing rare fruit. In fact, they might consider it serendipitous and really appreciate it.