Allow orders to answer for the merge_vars as well as User.

[sterrym]

For instance, if you want to add the :first_name, :last_name, you could add an order_decorator and delegate the methods: delegate :first_name, :last_name, to: :bill_address

[braidn]

@sterrym and this would be for merge vars on the order object? Does MailChimp have merge vars on their ecom objects?

[sterrym]

No, that's the merge vars on the list subscription in the case of the auto-subscribe config. In this case, we don't have a user model in context but we do have an order model being used for the subscription so I thought it would be good to be able to send the same merge vars along. In our case, it's not just nice, it was required :)

On Thursday, 21 January 2016, Braden Douglass notifications@github.com wrote:

@sterrym https://github.com/sterrym and this would be for merge vars on the order object? Does MailChimp have merge vars on their ecom objects?

— Reply to this email directly or view it on GitHub https://github.com/DynamoMTL/spree_chimpy/pull/71#issuecomment-173574518 .

Tim Glen Tag Digital Studios Inc. p: 226-971-0840 tim@tagstudios.io | http://www.tagstudios.io Crafting outstanding custom online tools

[braidn]

@sterrym so these merge vars would be the items from the Order and not the User? Couldn't these be incorrect for the user since the user maybe using this order as a 'gift'? I can see this updating the Subscriber object in MC with merge vars that may not be "correct"

[sterrym]

But that's a question of implementation. For instance, if I want :first_name in my subscription, I can choose how to implement that in my order model. I can check for a user and fall back to the billing address. In the case of a gift, the billion information should still be "correct" since it's the info on the purchaser.

On Thursday, 21 January 2016, Braden Douglass notifications@github.com wrote:

@sterrym https://github.com/sterrym so these merge vars would be the items from the Order and not the User? Couldn't these be incorrect for the user since the user maybe using this order as a 'gift'? I can see this updating the Subscriber object in MC with merge vars that may not be "correct"

— Reply to this email directly or view it on GitHub https://github.com/DynamoMTL/spree_chimpy/pull/71#issuecomment-173580141 .

Tim Glen Tag Digital Studios Inc. p: 226-971-0840 tim@tagstudios.io | http://www.tagstudios.io Crafting outstanding custom online tools

[braidn]

@sterrym currently though, the order model doesn't perform any modifications on the MC subscriber object. This is the implementation and it's rather safe because it doesn't allow new user's to inadvertently update their subscriber MC objects with data from their orders. Are you recommending that we remove this safety net?

If so: how can we do this in a safe manner where new users of the gem don't "shoot themselves in the foot" while preserving backwards compatibility?

[sterrym]

Okay, I see your issue now. I also see that we're coming at this from two different angles. Let me explain my use case: we are adding customers (purchasers) to a mailing list for follow-ups - things like service questionnaires and service contacts. On our store, we have no need for Users to automatically get added to a list, only people who have purchased something. Could we make this option configurable?

[braidn]

@sterrym sorry it has taken me a bit to get back to you. My recommendation to solve the following:

we have no need for Users to automatically get added to a list, only people who have purchased something.

would be to still sync these users. Then use MailChimp's fantastic segmenting tools to cull the users who have orders (synced through spree_chimpy). This also gives you great visibility into who your users are(because these can be segmented as well) who buy nothing. Now the marketing team has a list of users that can be targeted for drip campaigns, user retention, abandoned cart emails, etc!

[sterrym]

That's all fine, but they still would get added with no first or last name or any other merge vars. I'm just suggesting that if the methods for the merge vars are available, they could get used in this context.

[braidn]

@sterrym They would get added with firstname and lastname from the user model no?

The reason I hesitate to do this through the order is because of what I outlined above along with the fact that it bumps up against SRP. Really we are just updating order's for a user, not updating merge vars, information about them, or their email. This keeps the update to the user's orders very idempotent, much like a Rails migration. Over, wildly updating the user who made the order.

If you want to update the User at a point that's not the User#update method, then maybe utilizing something like Gibbon for this is a better choice.

[sterrym]

That totally makes sense. Is there a way to check for the existence of a user and only create one with their merge_vars if one doesn't exist?

On Thursday, 28 January 2016, Braden Douglass notifications@github.com wrote:

@sterrym https://github.com/sterrym They would get added with firstname and lastname from the user model no?

The reason I hesitate to do this through the order is because of what I outlined above along with the fact that it bumps up against SRP. Really we are just updating order's for a user, not updating merge vars, information about them, or their email. This keeps the update to the user's orders very idempotent, much like a Rails migration. Over, wildly updating the user who made the order.

If you want to update the User at a point that's not the User#update method, then maybe utilizing something like Gibbon for this is a better choice.

— Reply to this email directly or view it on GitHub https://github.com/DynamoMTL/spree_chimpy/pull/71#issuecomment-176195165 .

Tim Glen Tag Digital Studios Inc. p: 226-971-0840 tim@tagstudios.io | http://www.tagstudios.io Crafting outstanding custom online tools

[braidn]

@sterrym the only way to check the assistance of a user would be to grab all emails from Mailchimp's list dump function and filter out the email from that list. Also if someone checks out using an email during guest checkout, then creates an account in your system using the same email (highly likely scenario) spree_chimpy just updates their existing record in Mailchimp, over creating another one. There is a good chance that the merge vars that you are looking for will be updated at that point.

There is so much segmenting you can do through the merge vars at this level. That's why I stress that folks don't blanket update them through the order process. It gives store owners a lot of touch points for emails in the future that get people back to the site, updating their information and maybe buying something new.

[braidn]

going to close this for now.