I am looking for a maintainable solution to track the source "events" when uploading a list of participants to HubSpot.
Now, I want to walk you through some of the considerations I've made and ask for advice for the most elegant, simple, and maintainable solution.
By default the Original Source will be "Offline Source", this is ok. But, we wat to distinguish between e.g. "Event" and "Webinar" and between the different titles as well. I think the Original Source Drill Down 1 and 2 should be adequate for that.
Now, some problems: Entering the data can be difficult. If someone writes "Event" instead of "Events", the reporting on Events would break.
Also, if I override the Original Source data, there could be problems, for instance, if the contact is already in the database, I don't want to override the Original Source but the Record Source, otherwise the data entry would be false.
Also, to be consistent with HubSpot, I should also update the Record Source (and possibly other fields I am not aware of).
To avoid problems with the data entry, I am thinking about writing a workflow that checks for all these things so that after an event, one only has to enroll a list of contacts into this workflow. However, I do not like this solution very much, as one would always need to update the workflow according to the name of the event.
I would like to hear your thoughts on this. Is there a straightforward way of doing it?
I am looking for operational elegance here, if at all possible.
Tracking event interactions through the original source properties is not a good idea, in my opinion – as you probably also want to see this information in an easy accessible way if it was not the first (original) touchpoint.
If reporting is the biggest concern, I'd recommend using a custom property for this – which would allow you to clean it up, if needed. The drill-down properties don't allow for editing. With custom properties, you could train teams to map their event source column from a file to that custom property and make sure to not overwrite existing values – keeping the original value always present. In reports, you would then have to report on a separate field, yes. (I prefer this a scenario where teams need to keep import guidelines in mind. My experience is that people with import permissions will rarely follow all process requirements. It will not be clean in a way that you would need it, I'm fairly certain of that.)
Personally, I'm a fan of multiple checkboxes property to see who participated in a certain event, where each checkbox option corresponds to an event. A workflow could also easily log the first known value to a "First event interaction" field.
Tracking event interactions through the original source properties is not a good idea, in my opinion – as you probably also want to see this information in an easy accessible way if it was not the first (original) touchpoint.
If reporting is the biggest concern, I'd recommend using a custom property for this – which would allow you to clean it up, if needed. The drill-down properties don't allow for editing. With custom properties, you could train teams to map their event source column from a file to that custom property and make sure to not overwrite existing values – keeping the original value always present. In reports, you would then have to report on a separate field, yes. (I prefer this a scenario where teams need to keep import guidelines in mind. My experience is that people with import permissions will rarely follow all process requirements. It will not be clean in a way that you would need it, I'm fairly certain of that.)
Personally, I'm a fan of multiple checkboxes property to see who participated in a certain event, where each checkbox option corresponds to an event. A workflow could also easily log the first known value to a "First event interaction" field.
It was a good tip to go for the native marketing events. I have disliked the feature in the past, but it seems like it is usable for list uploads.
I will keep the custom property workaround in mind in case this does not work in a satisfactory manner, although I do try to avoid creating custom properties whenever possible.
Anyway, I think this will work, so, thanks a bunch!