Closed joshnuss closed 11 years ago
@joshnuss you want these other subscriptions to go to a different list ? why not keep it al in the same list ?
@johanb in mailchimp, would it be useful to target each group separately? (i.e. subscribers with accounts vs subscribers without accounts). cause then we would need 2 seperate lists. or maybe we can add a source field?
also the merge vars may be different (or non present) for a user who subscribed without an account.
@joshnuss you can just set up groups for the type of user. I like to work with a "customer" and "subscriber" group.
that works.
would that just be another merge var?
Not sure yet, I think they are static segments, not merge vars.
I'll give it a shot tomorrow.
I've looked into it and we can use either "groups" or "static segments". Users can influence groups themselves, however they have no influence over their segments. Therefor I think we can best use static segments. Now we could create 2 segments, 1 for each type, or just create 1 segment. I think it works best to create just a static segment for "customers" and add users with eccomerce (and all merge tags) to this segment.
That sounds perfect :D
can we make the name of the static segment a configuration option? with default to "Customers"
On Thu, May 9, 2013 at 9:40 AM, Johan Bruning notifications@github.comwrote:
I've looked into it and we can use either "groups" or "static segments". Users can influence groups themselves, however they have no influence over their segments. Therefor I think we can best use static segments. Now we could create 2 segments, 1 for each type, or just create 1 segment. I think it works best to create just a static segment for "customers" and add users with eccomerce (and all merge tags) to this segment.
— Reply to this email directly or view it on GitHubhttps://github.com/DynamoMTL/spree-hominid/issues/2#issuecomment-17664638 .
The user should be able to subscribe to the "newsletter" without going thru the signup process.
For the model, what do you think about calling it "Subscriber"? Then we can reuse the existing Subscription class like we do in the user class. (maybe we could refactor that stuff into a module?)
The subscribers should be added to a separate mail chimp list.
Thanks @johanb for suggesting this feature.