Closed mgirouard closed 6 years ago
Can I get some feedback on this? If there's a better approach I'd be happy to go that direction.
Thanks for the PR, Michael! Only note I have here is that the recipientEmail
field shouldn't be a requirement for anonymous events, note the signature of the ruby analog.
While we have special handling for a recipient
field if present, you could equally create a campaign for which the "To" field is set to something custom like {{ event.email_address }}
(also because of our support for non-email delivery types, the recipient may not be an email address!)
Aside from that, the rest looks 👍 for merging - I'll have someone from the team take a look at getting an updated version rolled out this week
Ah ha! That makes it clear. I had misunderstood how anonymous events work and based it off of the Anonymous Invite Emails article with too much focus on the recipient
field.
I'll have an updated patch later today!
@hownowstephen Finally circling back on this. The signature is simplified now to just the event name and the attributes. Tests pass and I can confirm I see the events coming through in our environment.
Let me know if this works for you.
Any chance we can get this merged today? We're using my fork on a project and this is pretty much the last item on our list to close out the project.
Let me know if you need me to jump on anything!
Looks great, thanks for tackling that!
Thank you!
I have an app which relies on anonymous events for a significant portion of events we send. It seems as this isn't supported by the Go client, but is in other clients (eg: ruby).
What do you all think about adding a similar method to the
CustomerIO
struct?Happy to PR something like this if it's helpful.