Best practice for dealing with email address confirmation?

[marckohlbrugge]

The example code shows this:

after_create_commit do
  OnboardingCampaign.add(self)
end

Which conveniently omits the fact that we'll want to hold off sending emails until the user has confirmed their email address.

The intuitive solution is to add a segment check to the campaign like below, but I believe this won't work as expected. The campaign will be triggered, the user does not fit the segment yet, and thus the campaign will never be sent. Even after email confirmation.

class OnboardingCampaign < ApplicationCampaign
  segment :confirmed?
end

The proper solution then seems to be to hold off on adding the user to the campaign, until the user has confirmed their email address. We could add OnboardingCampaign.add(user) in a ConfirmationsController.

This seems like a pragmatic solution, but it doesn't work well if you also use OAuth logins where email confirmations can be skipped. Which means we'll need to add another OnboardingCampaign.add(user) somewhere in the OAuth signup process.

So my question is this: what's the best practice for holding off on sending campaigns until the user has confirmed their email address?

[joshuap]

@marckohlbrugge what you suggested—waiting until they confirm their email to add them—is the right way, but I've also experienced some friction with having multiple onboarding paths. I don't have a great answer, except that you could add them to the campaign using an after_save callback in the User model with an if: ->(u) { u.confirmed? } condition, so it adds them regardless of where the email was confirmed (assuming the OAuth process auto-confirms the email). Or, you could have some kind of service object or decorator that you call from both places that does all of the post-confirm onboarding stuff.

[joshuap]

I have thought about other ways of doing this potentially, like instrumenting the app for events and then having a way to subscribe to those events. You could technically do that with ActiveSupport::Notifications (we use that a bit), but I don't think it's simpler. Some kind of event-driven workflow API in the future could be interesting for driving more complex campaigns/workflows though.

[marckohlbrugge]

Yeah I actually use ActiveSupport::Notifications a lot for that type of stuff. But it's not idempotent, because there's no persistency. (Which could lead to duplicate events, etc)

I also have a Event model to track important user events. I might elaborate on that, add a "user_is_confirmed" event, and have the campaign "subscribe" to that.