You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been following the two discussions on private vs public list subscriptions (#2301, #2251), and recently came across this thread too: #1956
After doing some tests on my end, I had some questions / comments / clarifications:
Public Lists in the Subscription Management Page
When creating a new list, users are met with the following help text under the "Type" field:
Public lists are open to the world to subscribe and their names may appear on public pages such as the subscription management page.
In another thread, Kailash mentioned that "Public lists: Their names are public on built-in subscription forms, optin-confirmation e-mails, ==unsubscribe page== etc."
I think the wording here should be tweaked, because the only public lists shown in subscription management (via the Unsubscribe link in the footer) are the ones that the contact is subscribed to. From my own tests, the entire list of public subscriptions isn't revealed to the subscriber.
Pro of this: great for keeping semi-private lists separate, and not allowing just anyone to subscribe.
Cons: Based on the wording of the help text, some users may be under the impression that their subscribers can use the manage preferences option to opt into other lists, which may be the desired behaviour...
It may be worth adding a field for fields that are public-public (should be shown on the subscription management page for all contacts) vs semi-public (only shown to those who are signed-up, not shown on the public subscription page)
Private lists and the API
Kailash mentioned in that same thread that: "Private lists: These are never exposed to the public subscription pages. Their names are never revealed in e-mails (even in opt-in confirmation and on unsubscribe pages). ==Their list UUIDs cannot be used in the public subscription APIs that you can use to make custom forms,== or the built-in public subscription form. These are fully private and have no interface to the outside world."
I've been following the two discussions on private vs public list subscriptions (#2301, #2251), and recently came across this thread too: #1956
After doing some tests on my end, I had some questions / comments / clarifications:
Public Lists in the Subscription Management Page
When creating a new list, users are met with the following help text under the "Type" field:
In another thread, Kailash mentioned that "Public lists: Their names are public on built-in subscription forms, optin-confirmation e-mails, ==unsubscribe page== etc."
I think the wording here should be tweaked, because the only public lists shown in subscription management (via the Unsubscribe link in the footer) are the ones that the contact is subscribed to. From my own tests, the entire list of public subscriptions isn't revealed to the subscriber.
Pro of this: great for keeping semi-private lists separate, and not allowing just anyone to subscribe.
Cons: Based on the wording of the help text, some users may be under the impression that their subscribers can use the manage preferences option to opt into other lists, which may be the desired behaviour...
It may be worth adding a field for fields that are public-public (should be shown on the subscription management page for all contacts) vs semi-public (only shown to those who are signed-up, not shown on the public subscription page)
Private lists and the API
Kailash mentioned in that same thread that: "Private lists: These are never exposed to the public subscription pages. Their names are never revealed in e-mails (even in opt-in confirmation and on unsubscribe pages). ==Their list UUIDs cannot be used in the public subscription APIs that you can use to make custom forms,== or the built-in public subscription form. These are fully private and have no interface to the outside world."
When testing my Listmonk API automation with Zapier, I was able to POST/add subscribers to private lists using the list's ID. (Related: #2296)
Is the quoted info outdated?
The text was updated successfully, but these errors were encountered: